Java *

Друзья! Если вы хотите прокачать навыки в сфере Java-разработки, у нас замечательная новость! Теперь у вас есть возможность пройти обучение по отдельным модулям программы «Java-разработчик. Middle Developer».  Вам не обязательно проходить весь курс целиком — выбирайте темы, которые вас интересуют, и погружайтесь в изучение. 

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

Модули программы, которые вы можете купить и пройти самостоятельно:

✔️ Java: ООП и функциональная парадигма

✔️ Разработка бизнес-приложений на фреймворке Spring 

✔️ Работа с базами данных в Java

✔️ Архитектура REST

✔️ Вспомогательные инструменты Java-разработчика

✔️ Избранные классы и стандартные библиотеки

✔️ Многопоточность в Java

👉Посмотреть подробную программу «Java-разработчик. Middle Developer» и выбрать модули для изучения 👈

Всем привет!

Давненько не было постов на канале, что поделать - конец квартала, авральный режим on. Но я вернулся)

Java всегда славилась своим boiler plate кодом. Ремарка - конечно же не только boiler plate, но сейчас про него и про борьбу с ним. Борьба идет, и в Java 16 (а точнее в Java 14 но в режиме preview) появились records, они же записи.
Делаешь вот такое объявление:
public record Point(int x, int y) {}
и получаешь из коробки конструктор, getter, equals(), hashСode() и toString().
Т.е все то, что раньше приходилось писать руками или использовать Lombok. Ага, Lombok. Т.е. он стал не нужен? Не совсем. Если внимательно глянуть на список того, что под капотом делает record, то можно заметить, что там нет setter-а. Т.е. record - это иммутабельный объект и value object. Две записи с одним и тем же набором полей всегда равны. Это не баг, это фича. Маленькое дополнение - record еще меняет классический getter c getXyz на просто xyz(), но это детали. Еще дополнение - вот тут среди прочих фичей Java 17 достаточно интересно о работе с record.

Т.е. получается, что record заменяет @Value из Lombok.

Но не заменяет:

1. полноценный @Data - изменяемый класс без boiler plate

2. кейс, когда мы не хотим все сразу getter, toString() ... а хотим только часть этих методов

3. @Builder - тут проще показать, чем объяснять:
   Person.builder().name("Adam Savage").city("San Francisco").build();

4. @Log - простое добавление логгера в класс

5. и наконец @SneakyThrows - если вы не любите checked exception

Один из плюсов нашей программы «Java-разработчик. Middle Developer» гибридный формат обучения. Мы решили обсудить его плюсы и особенности с одним из авторов и тренеров курса Игорем Судакевичем. 26 сентября проведем прямой эфир «Java Pro: гибридная академия разработчиков». 

Поговорим, почему для изучения Java прекрасно походит гибридный формат, и в чем его отличия от обычного вебинарного формата.  А также обсудим, какие скиллы нужно прокачивать, чтобы вырасти в Java-разработчика уровня Middle.

📅 Дата: 26.09.2024

⏰ Время: 18:00-19:00 (Мск)

👨‍🎓  Спикер: Судакевич Игорь — преподаватель международного уровня, более 15 лет работает в IT. Уполномоченный инструктор корпорации Oracle. Магистр компьютерно-информационных технологий. Инструктор платформы Udemy. 

👉 Записаться 👈

Всем привет!

Расскажу про один поучительный факап из моей практики.

Более 10 лет назад. Стартап. Я на тот момент и СТО, и разработчик в одном лице. Есть задача, в целом понятная. Декомопозирую на микросервисы и подзадачи, начинаю пилить. Дохожу до XML binding - преобразования XML в объекты. Тогда API в основном были XML. Решил погуглить - что есть на рынке. Кроме известного многим JAXB нахожу JiXB. Не известный тогда, тихо умерший сейчас. Читаю описание и нахожу бенчмарк, показывающий что он ... скажем в 1.5 раза быстрее JAXB. Думаю - о, круто, надо брать. Начинаю прикручивать к Spring. Наталкиваюсь на кучу подводных камней - это не работает, документации мало, ошибки не информативные и не гуглятся. В общем убил неделю на прикручивание к проекту одной библиотеки. В итоге все заработало, конечно. А проект не был доведен до работающего состояния и так и не взлетел.

Итоги. До сих пор стыдно за такое решение по следующим причинам:

1. речь про стартап, т.е. нужно быстро создать работающий прототип, а не исследовать новые технологии

2. преждевременная оптимизация - данных по требуемому RPS и доступному железу на тот момент у меня не было. Нагрузочное тестирование не проводилось. Стал бы JAXB узким местом - не факт

3. использовать в промышленной разработке не доказавшие свою зрелость библиотеки - это риск. Очень важны сообщество и работающие без бубна связки, например, Spring+JAXB. А риск должен быть оправдан, а еще должен быть план отката. Не взлетело, сыро - откатываемся на надежный вариант

Weekend Offer для Java-разработчиков, системных аналитиков и QA-инженеров (backend)

24—25 августа проведем Weekend Offer в Нефинансовые сервисы Т-Банка сразу для трех профессий: Java-разработчиков, системных аналитиков и QA-инженеров (backend). Это самый быстрый путь к офферу: вы сможете пройти все этапы интервью за выходные.

Нефинансовые сервисы — целая экосистема лайфстайл-продуктов в банке: от подписок и билетов в кино до онлайн-бронирования отелей. Вкратце — все то, что делает жизнь клиентов проще и счастливее. В начале Weekend Offer проведем велком-встречу с экспертом и расскажем больше о том, как работают сервисы.

Мы ждем:

— Java-разработчиков, которые владеют навыками в любой из технологий: Spring, Quarkus, Micronaut, Ktor или Vert.x.

— Системных аналитиков, которые работали с REST/gRPC/graphQL и брокерами сообщений — Kafka/RabbitMQ.

— QA-инженеров с опытом работы в тестировании бэкенда и автоматизации тестирования с использованием Java, Kotlin или JS.

Если у вас есть опыт от 3 лет — приходите и создавайте прорывные сервисы вместе с нами. Заявку можно оставить до 21 августа на сайте.

Учебный центр IBS разыгрывает грант на бесплатное обучение на программе «Java-разработчик. Middle Developer».

Переходите по ссылке, выполняйте задание и присылайте его на адрес education@ibs.ru с пометкой «Розыгрыш гранта». Комиссия из экспертов компании IBS наградит победителей:

🥇 Участник, занявший 1-е место, получит бесплатное обучение на программе «Java-разработчик. Middle Developer».

🥈 Участник, занявший 2-е место, — скидку 50% на обучение на программе.

🥉 Участник, занявший 3-е место, — скидку 25% на обучение на программе.

Работы принимаются до 21 августа включительно.

О курсе

Программа «Java-разработчик. Middle Developer» составлена с учетом логики освоения Java: каждая тема плавно переходит в следующую, что делает процесс обучения более интуитивным и понятным. 

Вы потренируетесь в решении семи реальных задач и освоите использование ChatGPT.

Обучение проходит в гибридном формате. 

В конце учебы выдается диплом о профессиональной переподготовке.

Желаем удачи! 🤞

Всем привет!

Я уже писал о пользе стандартизации на примере формата данных для сохранения информации о сборке - cyclonedx. А недавно в посте про работу с исключениями упоминал библиотечку для возврата ошибок в API - jdoctor.

Так вот - стандартизация добралась и сюда)

Во-первых, как выяснилось - уже с 2016 года есть стандарт "Problem Details for HTTP APIs"
Во-вторых - в Spring Boot 3, т.е. с 2021 года, появилась его имплементация. Вот неплохое описание у baeldung
Если вкратце - ответ при ошибке будет иметь стандартизированный вид похожий на такой:
{
"type": "about:blank",
"title": "Bad Request",
"status": 400,
"detail": "Invalid request content",
"instance": "/sales/calculate"
}

Библиотеки, решающие подобную задачу в Java, уже были:

1. уже упомянутый jdoctor

2. error-handling-spring-boot-starter

   Но думаю, что именно данное решение - от Spring, да еще по стандарту - имеет шансы популяризовать данную практику.

Что еще хочется отметить:

1. стандартизация рулит) Каждый поставщик API разрабатывает формат для ответа при ошибке, каждый потребитель - специфический код для его обработки. А при этом понятно, что формат информации об ошибке мало зависит от бизнес-процесса

2. еще в 2018 году в Сбере формат ответа для REST был стандартизирован. Но, увы, формат отличается от RFC, а область применения ограничена взаимодействием с фронтом.

На GitHub представлен проект OpenTTY Java Edition. Это эмулятор терминала OpenTTY для старых телефонов с поддержкой J2ME (Java ME, ранее — Java 2 Micro Edition).

Исходный код проекта OpenTTY Java Edition написан на Java, в нём доступны основные команды, есть поддержка Debug Tool, shell script, Xorg server, htop (show memory usage), netstat (verify network), nano (temporary notepad), wget (save website html) и tty (show console path).

Файл OpenTTY.jar занимает размер 43 КБ.

Приглашаем на новый бесплатный вебинар «Реактивный GRPC».

Важнейшая проблема при разработке реактивных приложений — передача реактивного стрима по сети. В рамках семинара разберем  реализацию поверх протокола GRPC. Изучим место этой реализации среди остальных, поймем как устроено это решение, разберёмся в некоторых допущениях, которые оно использует, и обсудим практические примеры использования данной технологии.

📅 Дата: 19.07.2024

⏰ Время: 17:00-19:00 (Мск)

На вебинаре:

✔️ Сетевые реактивные стримы

✔️ GRPC

✔️ Реактивный GRPC

✔️ Особенности Flow Control в реактивном GRPC

✔️ Практические примеры использования реактивного GRPC

👨‍🎓 Спикер: Кузнецов Николай — Java-разработчик в компании АО «Синхро» (проект «Столото» ex СБЕР). Обладает опытом разработки высоконагруженных систем более 5 лет. Автор ряда научных публикаций в области распределённых и децентрализованных систем.

➡️ Зарегистрироваться ⬅️

Выкатываем лето на прод в Казани!

Наш летний ИТ-фестиваль «Сезон кода» проведем 13 июля. Будем делиться опытом, говорить про технологии, танцевать и уже по доброй традиции помогать «Семейному дому» в Казани.

Что по программе:

— доклады по Java, Scala, QA, Mobile и Data от инженеров Т-Банка, Сбера, VK и Магнит Маркет;
— квиз и кастомные настолки, чтобы поиграть в перерывах;
— спорт-, лаундж- и фотозоны, где можно размяться, отдохнуть и сделать пару снимков на память.

Стать участником ИТ-феста просто: нужно зарегистрироваться и внести пожертвование от 1000 ₽. Подробности на этой странице.

Лето, код, комьюнити 💛

#сезон_кода

Всем привет!

Какие компиляторы есть в Java?
Простой ответ - javac. Компилирует исходники в байт-код, который исполняет JVM. Исполняет и оптимизирует. И основные оптимизации происходят именно runtime, а javac является "примитивным". Идея в том, что собирается статистика использования кода, часто используемый код компилируется в "нативный" для конкретного процессора, а неиспользуемый удаляется. Получаем плюс один компилятор - JIT (Just in Time). Только исторически компиляторов два: С1 - быстрый, но оптимизирующий не оптимально))), второй C2 - медленный и хорошо оптимизирующий. Сейчас они используются в паре, см. https://for-each.dev/lessons/b/-jvm-tiered-compilation

А можно без байт-кода? Да, есть AOT (Ahead of Time) компилятор, поставляется в GraalVM https://graalvm.org/latest/reference-manual/native-image Он сразу компилирует в требуемый "нативный" код. А если поддержки требуемой процессорной архитектуры нет? Растет популярность ARM архитектур, а там тот еще зоопарк. А для этого уже существует промежуточный язык и набор компиляторов LLVM https://llvm.org/. Что-то типа Java байт-кода, только не привязанный к Java. GraalVM его поддерживает https://graalvm.org/latest/reference-manual/native-image/LLVMBackend
А можно его использовать и как runtime компилятор? Почему нет, в Azul JDK отказались от C1\C2 и сделали свой компилятор с LLVM - https://azul.com/products/components/falcon-jit-compiler

А еще есть компиляторы Kotlin, Scala, Groovy, Jython, JRuby... В общем я сбился со счета)

Всем привет!

Продолжаю серию полезных видео - https://youtu.be/j-i3NQiKbccТут по полочкам расписывает как работает логирование в Java.

Краткий конспект по архитектуре логирования:

• адаптер - предоставляет API, которое вызывается из кода. Их всего 3 - SL4J, JCL (Apache Common Logging) и JBoss Logging. Самый распространенный и рекомендуемый - SLF4J

• bridge - нужен, когда какая-то библиотека использует не тот адаптер, что мы хотим. По сути адаптер на адаптер, который эмулирует API, вызываемое из кода, и пробрасывает вызовы в нужный адаптер, как правило SLF4J. Понятно, что когда у нас есть адаптер на адаптер, есть риск бесконечной рекурсии. Про это надо помнить)

• движок логгера - компонента, которая пишет логи. Примеры: log4j, log4j2, logback, JUL\JDK (встроенный в JDK)

• appender - компонент, определяющий физическое место, куда пишутся логи: консоль, диск, БД, MQ... Вот полный список для log4j2 https://logging.apache.org/log4j/2.x/manual/appenders.html

• фильтры и конверторы - позволяют отфильтровать или преобразовать сообщения на клиенте

Плюс 3 хороших совета:

• соблюдать гигиену classpath - чистить его от лишних библиотек

• логи могут стать основой мониторинга. Мы отбрасываем специальным образом размеченную запись в лог, которая после обработки становится событием мониторинга

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

И 2 полезные утилиты - миграторы на logback и SLF4J с альтернативных библиотек.

Всем привет!

Нашел отличное видео по исключениям в Java https://www.youtube.com/watch?v=UIbbNsta2UE

Краткий конспект, не влияющий на рекомендацию посмотреть видео:

1. затраты на выбрасывание исключений конечно же есть, но если исключение в вашем сервисе = ошибке, то проблем с производительностью не будет. Т.к. частота ошибок сильно меньше RPS.

2. если ваши исключение выбрасывается в строго определенном месте кода - можно убрать из него stacktrace, это неплохо увеличит производительность. На самом деле если просто не обращаться к stacktrace, то она уже увеличится, но для надежности лучше вообще не прикреплять stacktrace. Или использовать StackWalking API https://www.baeldung.com/java-9-stackwalking-api

3. самый спорный и опасный совет для предыдущего кейса - закэшировать исключение, так его выброс будет еще быстрее. Но по сути это старый добрый "go to". Использовать с осторожностью!)

4. исключение должно содержать весь контекст ошибки, в идеале с предложениями по ее исправлению. Чтобы структурировать информацию об ошибке есть библиотека https://github.com/melix/jdoctor Активность в репозитории слабенькая, но сама идея мне нравится.

5. как известно, есть исключения, которые не стоит ловить - например, OOM и StackOverflow. А если очень хочется OOM поймать?) Тогда нужно заранее создать необходимые для сохранения информации о проблеме объекты, ведь после OOM памяти уже не будет.

   А еще из интересного - после просмотра видео станет понятно, как работает SneakyThrows в Lombok

✨ Избавляемся от хардкода в Java-приложении с @FieldNameConstants

Если вы работали с JPA Criteria API, то вам точно приходилось хардкодить название полей:

public Specification<Car> where(@Nullable CarFilterDto carFilter) {
    return (root, query, cb) -> cb.equal(root.get("type"), carFilter.getType());
}

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

@FieldNameConstants
public class FieldNameConstantsExample {
  private final String iAmAField;
  private final int andSoAmI;
  @FieldNameConstants.Exclude private final int asAmI;
}

и вот во что он превратится:

 public class FieldNameConstantsExample {
  private final String iAmAField;
  private final int andSoAmI;
  private final int asAmI;
  
  public static final class Fields {
    public static final String iAmAField = "iAmAField";
    public static final String andSoAmI = "andSoAmI";
  }
}

Также, можно:

• генерировать енам вместо констант

• поменять название статического класса

• поменять уровень доступа полей

• генерировать только для явно включенных полей

@FieldNameConstants(asEnum = true,
        innerTypeName = "StaticClassName", 
        level = lombok.AccessLevel.PRIVATE, 
        onlyExplicitlyIncluded = true)

👨‍💻 Джуниор

Учим Java: с жёстким тестовым, зато бесплатно и с приглашением на стажировку

Надеюсь, это был достаточно вовлекающий заголовок. Переходим к делу. 

Уже 5 лет Clevertec проводит внешние курсы по бэку, чтобы растить разработчиков с нужным стеком и компетенциями под финтех-проекты. В последние пару лет в каждом наборе получаем 1000+ заявок, после тестовых отбираем 30-40 человек и погнали.

Это классический курс с лекциями, домашками (с дедлайном) и промежуточными собесами. Длится 4-5 месяцев. Онлайн.

Тема не для новичков. Обычно отбор по тестовым проходят те, кто уже учил Java сам или на других курсах. Но есть бонус: если хорошо справляешься, то можешь получить приглашение на стажировку до окончания курса. Поэтому если давно в теме и хочешь ускориться с первой работой в айти – надо пробовать.

Курс всегда получает крутой фидбек за обратную связь и поддержку. 

Сами удивляемся, как ребята находят время и силы менторить студентов и писать подробные комменты к домашкам.  

Наши бэки работают в финтехе и учат стеку, который практикуют сами. Прокачаешь Core, Spring и CI/CD и научишься работать в команде. Это тоже важно для погружения.

Хочешь с нами?

До 1 июля заполни анкету предзаписи.
После 1 июля жди в почте тестовое и инструкции.

Всем Java этим летом!

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

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

Дата: 16.05.2024
Время: 18:00-19:00 (МСК)

Регистрация по ссылке.

Axiom JDK заявила о выпуске Axiom JDK Express. Axiom JDK Expres представляет собой российскую среду исполнения Java c улучшенной производительностью. В новой среде была оптимизирована платформа Java. Это позволило ускорить Java‑приложения до 15% без дополнительных затрат на оборудование. По словам разработчиков, благодаря полной совместимости со стандартом миграция на Axiom JDK Express с Java SE и сборок OpenJDK происходит бесшовно.

Новая среда улучшает работу LTS‑версий Java 8 и 11 с долгосрочной поддержкой, утверждают разработчики. Как они рассказали, почти половина всех Java‑приложений использует Java 8 и 11. При переходе этих приложений на Axiom JDK Express они получат значительный прирост скорости и экономию аппаратных средств без переписывания кода.

Axiom JDK Express объединяет виртуальную машину версии JVM 17 и среду исполнения JDK 8 или 11, повышая производительность систем до 15%. При этом не нужно менять версию фреймворка или код приложения. Достаточно изменить только один компонент вместо полноценной миграции на новый релиз JDK. Среда исполнения Axiom JDK Express ускоряет системы до уровня версии JDK 17 без изменений кода, включая сервер приложений Libercat.

Среди улучшений JDK 8:

• обновление механизмов сборки мусора, включая поддержку суб‑миллисекундных пауз и терабайтной кучи во всех версиях;

• запуск на 10% быстрее;

• скорость сжатия на 85%;

• скорость распаковки на 113%.

Также Axiom JDK рассказала, что её инженеры будут поддерживать JDK 8 до марта 2031 года,

Сегодня в 18:00 в рамках запуска новой программы «Java-разработчик. Уровень Специалист» пройдет онлайн-встреча с автором курса Судакевичем Игорем.

Обсудим:
какие навыки стоит освоить, чтобы стать востребованным Java-разработчиком;
как строится обучение на курсе «Java-разработчик. Уровень Специалист».

Дата: 22.04.2024
Время: 18:00-19:00 (МСК)

Спикер: Судакевич Игорь — преподаватель международного уровня, более 15 лет работает в IT. Уполномоченный инструктор корпорации Oracle. Магистр компьютерно-информационных технологий. Инструктор платформы Udemy.

Регистрация по ссылке.

Первый предварительный релиз порта Foreign Function & Memory API для Android.

С выпуском стабильной версии JDK 22 в конце марта, вышла окончательная версия FFM API — современного переосмысления доступа к нативной памяти и функциям. Примечательно, что его история начиналась ещё в JDK 14 несколько лет назад, тогда же я и обратил на него своё внимание. Мне стало интересно, возможно ли без поддержки со стороны платформы полноценное портирование этого API, и ответ — ДА!

На скриншоте выше - пример из официальной документации, запущенный на android 8.0. В нём происходит вызов функции qsort из libc, при этом один из параметров — указатель на функцию сравнения. С помощью метода upcallStub можно создать указатель на MethodHandle как на нативную функцию, что и демонстрирует пример. Полная документация исходного апи доступна на официальном сайте oracle

Отдельно отмечу отличия:

• Полностью воссоздать API не получилось т.к. до android 9.0 отсутствует его важный компонент — класс VarHandle, поэтому был создан другой класс с теми же методами, но без полиморфного поведения (чуть хуже оптимизация)

• MemoryLayout`ы нулевого размера не разрешены (в исходном варианте их поведение не совпадает с фактическим в компиляторах C и C++)

• Временно не работают upcall вызовы из потоков, не подключённых к jvm. Скоро исправлю, но ещё не придумал оптимальный путь

• Вернул методы MemoryLayout.valueLayout и paddedStructLayout. Не знаю почему их убрали в конечной версии

• Возможно что-то ещё

Весь исходный код доступен на github