Всем привет! Это разработческий канал от сотрудников Red Collar.
Каждую неделю один из сотрудников компании рассказывает о своих задачах, сложностях, решениях, делится полезными ссылками и мыслями на тему разработки.
Стремимся применять современные языки и новые подходы в разработке, ценим качественную работу, любим сложные задачи и открыты к критике, если вы тоже — мы на одной волне. :)
В компании занимаемся двумя направлениями:
- Разработкой сложных продуктов, сервисов для сотен тысяч пользователей для ведущих финтех-, телеком-, IT-, HoReCa- и логистических компаний.
- Созданием эстетичных корпоративных и промосайтов, которые становятся лучшими в своей сфере и берут самые сложные международные награды.
По тегам можно найти темы:
#rdclr_frontend — #Vanilla_JS #JavaScript #React #WebGL
#rdclr_backend — #Java #Python #PHP #NN
#rdclr_DevOps
#rdclr_QA
#product (мысли, применимые к сервисно-продуктовым историям)
#aesthetic (про эстетичность интерфейсов) #teamlead — про роль, практики и рост в тим-лида
#optimization (про оптимизацию кода для скорости и плавности работы проекта) и #library (набор инструментов для упрощения жизни разработчика)
#read (полезные ссылки для изучения нового материала)
#meme (на посмеяться) и #news (новости)
Чтобы совместить два тега — введите оба в поисковую строку канала.
Каждую неделю один из сотрудников компании рассказывает о своих задачах, сложностях, решениях, делится полезными ссылками и мыслями на тему разработки.
Стремимся применять современные языки и новые подходы в разработке, ценим качественную работу, любим сложные задачи и открыты к критике, если вы тоже — мы на одной волне. :)
В компании занимаемся двумя направлениями:
- Разработкой сложных продуктов, сервисов для сотен тысяч пользователей для ведущих финтех-, телеком-, IT-, HoReCa- и логистических компаний.
- Созданием эстетичных корпоративных и промосайтов, которые становятся лучшими в своей сфере и берут самые сложные международные награды.
По тегам можно найти темы:
#rdclr_frontend — #Vanilla_JS #JavaScript #React #WebGL
#rdclr_backend — #Java #Python #PHP #NN
#rdclr_DevOps
#rdclr_QA
#product (мысли, применимые к сервисно-продуктовым историям)
#aesthetic (про эстетичность интерфейсов) #teamlead — про роль, практики и рост в тим-лида
#optimization (про оптимизацию кода для скорости и плавности работы проекта) и #library (набор инструментов для упрощения жизни разработчика)
#read (полезные ссылки для изучения нового материала)
#meme (на посмеяться) и #news (новости)
Чтобы совместить два тега — введите оба в поисковую строку канала.
Всем привет! Меня зовут Андрей и в компании Red Collar я занимаю позицию Backend Java-разработчика. На этой неделе у меня будет много ревью-кода от стажеров до middle разработчиков, поэтому вначале рассмотрим решения и инструменты, с помощью которых можно повысить качество проекта.
#rdclr_backend #java
#rdclr_backend #java
MapStruct
Сегодня утром я проводил код-ревью нашего java-стажера и заметил участок кода, который можно автоматизировать.
В разработке Spring-based приложений зарекомендовал себя подход разделения приложения на «слои» — Controller -> Service -> Repository (в базовом представлении). При его использовании важно следить, чтобы нижний слой не имел доступа к слою выше. Наших данных это тоже касается и, если в слое контроллеров у нас участвуют сущности БД, то это считается плохим тоном и требуется проводить рефакторинг. Тут нам на помощь приходят DTO (Data Transfer Object), в которые мы заносим данные из наших сущностей и оперируем уже ими.
И, чтобы не делать это вручную, можно использовать библиотеку MapStruct. В лучших традициях спринга она помогает с помощью «магических» аннотаций конвертировать один объект в другой, снимая с нас большой пласт работы.
Попробовав однажды, писать вручную уже не захочется!
Ссылка на библиотеку — https://mapstruct.org/
#rdclr_backend #java #library
Сегодня утром я проводил код-ревью нашего java-стажера и заметил участок кода, который можно автоматизировать.
В разработке Spring-based приложений зарекомендовал себя подход разделения приложения на «слои» — Controller -> Service -> Repository (в базовом представлении). При его использовании важно следить, чтобы нижний слой не имел доступа к слою выше. Наших данных это тоже касается и, если в слое контроллеров у нас участвуют сущности БД, то это считается плохим тоном и требуется проводить рефакторинг. Тут нам на помощь приходят DTO (Data Transfer Object), в которые мы заносим данные из наших сущностей и оперируем уже ими.
И, чтобы не делать это вручную, можно использовать библиотеку MapStruct. В лучших традициях спринга она помогает с помощью «магических» аннотаций конвертировать один объект в другой, снимая с нас большой пласт работы.
Попробовав однажды, писать вручную уже не захочется!
Ссылка на библиотеку — https://mapstruct.org/
#rdclr_backend #java #library
CriteriaApi
Не раз мы сталкивались с задачами на фильтрацию какой-либо выборки данных по определенным параметрам, которые могут либо присутствовать, либо нет. Как же лучше всего реализовать данный фильтр?
Если делать прямо в лоб, то мы пишем большой SQL запрос, где будет перебор параметров фильтра в блоке where. Минусы тут очевидны: при увеличении размеров фильтра будет раздуваться и SQL запрос, из чего следует повышение сложности запроса, ухудшение его читаемости, сложность дебага и рост ошибок.
Тут на помощь приходит CriteriaApi. Данный пакет инструментов позволяет динамически строить запрос в БД, оперируя объектами, а не самим SQL. Вдобавок к этому, Spring фреймворк предоставляет нам интерфейс Specification<T>, который упрощает взаимодействие с CriteriaApi. Пример работы приведен на картинке ниже.
#rdclr_backend #java
Не раз мы сталкивались с задачами на фильтрацию какой-либо выборки данных по определенным параметрам, которые могут либо присутствовать, либо нет. Как же лучше всего реализовать данный фильтр?
Если делать прямо в лоб, то мы пишем большой SQL запрос, где будет перебор параметров фильтра в блоке where. Минусы тут очевидны: при увеличении размеров фильтра будет раздуваться и SQL запрос, из чего следует повышение сложности запроса, ухудшение его читаемости, сложность дебага и рост ошибок.
Тут на помощь приходит CriteriaApi. Данный пакет инструментов позволяет динамически строить запрос в БД, оперируя объектами, а не самим SQL. Вдобавок к этому, Spring фреймворк предоставляет нам интерфейс Specification<T>, который упрощает взаимодействие с CriteriaApi. Пример работы приведен на картинке ниже.
#rdclr_backend #java
Глобальная обработка ошибок
Непройденная валидация данных, отсутствие доступа, проблемы в бизнес-логике, внутренние ошибки сервера — типичные ситуации, возникающие в процессе работы большинства приложений. Наша задача, как бэкенд-разработчиков, обработать все эти исключения и передать клиенту в удобно читаемом и понятном виде, так как никто не любит полотно стек-трейса в респонсе сервера.
Задача состоит в следующем: отловить ошибку и превратить стек-трейс в понятое всем сообщение. В этом нам поможет «магия» от спринга в виде аннотации @RestControllerAdvise, которую мы повесим над классом-обработчиком. И так же аннотация @ExceptionHandler, с помощью который мы обозначаем, какие именно ошибки перехватывать.
Если Вам требуется возвращать не объект в респонсе, а какое-то представление (например, html), то можете воспользоваться @ControllerAdvise. Разница между ними такая же, как и между @Controller и @RestController. В итоге получаем единую точку обработки всех исключений, и если в приложении что-то случится, весь поток выполнения программы перейдет в RestControllerAdvise.
Также, глобальная обработка ошибок хороша тем, что мы можем задействовать i18n в единственном месте (с помощью MessageSource), а не размазывать логику по проекту.
#rdclr_backend #java
Непройденная валидация данных, отсутствие доступа, проблемы в бизнес-логике, внутренние ошибки сервера — типичные ситуации, возникающие в процессе работы большинства приложений. Наша задача, как бэкенд-разработчиков, обработать все эти исключения и передать клиенту в удобно читаемом и понятном виде, так как никто не любит полотно стек-трейса в респонсе сервера.
Задача состоит в следующем: отловить ошибку и превратить стек-трейс в понятое всем сообщение. В этом нам поможет «магия» от спринга в виде аннотации @RestControllerAdvise, которую мы повесим над классом-обработчиком. И так же аннотация @ExceptionHandler, с помощью который мы обозначаем, какие именно ошибки перехватывать.
Если Вам требуется возвращать не объект в респонсе, а какое-то представление (например, html), то можете воспользоваться @ControllerAdvise. Разница между ними такая же, как и между @Controller и @RestController. В итоге получаем единую точку обработки всех исключений, и если в приложении что-то случится, весь поток выполнения программы перейдет в RestControllerAdvise.
Также, глобальная обработка ошибок хороша тем, что мы можем задействовать i18n в единственном месте (с помощью MessageSource), а не размазывать логику по проекту.
#rdclr_backend #java
Ловушка @Transactional или использование Self-inject’ов
В бине имеется 2 метода: a() и b(), помеченных аннотацией @Transactional. Если мы из метода а() вызовем метод b() — как поведет себя транзакция метода b()?
Правильный ответ — транзакция метода b() не выполнится.
Один из самых популярных вопросов на собеседовании для java-разработчиков вплоть до middle позиций включительно. В реальной жизни тоже встречается довольно часто, поэтому стоит следить за аннотациями над методами и понимать, как они работают.
Почему же транзакция не выполнится? Дело в том, что когда мы делаем someService.callMethod() — вызывается метод Бина, а когда внутри a() дергаем b() — вызывается метод Класса, т.е. без каких-либо прокси-оберток Спринга и прочего. Именно из-за этого транзакция метода b() и не выполнится, потому что сам класс про неё ничего не знает.
Одним из вариантов решения этой проблемы, дабы сохранить транзакционность, является использование self-инжектов. Суть в том, что мы должны взаимодействовать не с методом b() напрямую, а через бин самого себя. Ниже приведен пример такой реализации.
#rdclr_backend #java
В бине имеется 2 метода: a() и b(), помеченных аннотацией @Transactional. Если мы из метода а() вызовем метод b() — как поведет себя транзакция метода b()?
Правильный ответ — транзакция метода b() не выполнится.
Один из самых популярных вопросов на собеседовании для java-разработчиков вплоть до middle позиций включительно. В реальной жизни тоже встречается довольно часто, поэтому стоит следить за аннотациями над методами и понимать, как они работают.
Почему же транзакция не выполнится? Дело в том, что когда мы делаем someService.callMethod() — вызывается метод Бина, а когда внутри a() дергаем b() — вызывается метод Класса, т.е. без каких-либо прокси-оберток Спринга и прочего. Именно из-за этого транзакция метода b() и не выполнится, потому что сам класс про неё ничего не знает.
Одним из вариантов решения этой проблемы, дабы сохранить транзакционность, является использование self-инжектов. Суть в том, что мы должны взаимодействовать не с методом b() напрямую, а через бин самого себя. Ниже приведен пример такой реализации.
#rdclr_backend #java
АОП. Аспектно-ориентированное программирование
Всем привет! С вами снова Андрей, java-разработчик. Мы продолжим говорить об экосистеме java и смежных вещах. Сегодня затронем АОП. Тема очень обширная, поэтому в этой мини-статье заденем минимальные основы.
В рамках Spring-фреймворка АОП является некой сквозной логикой, которую мы можем использовать в любом месте приложения, всего навсего повесив аннотацию (или с помощью xml-разметки). Также этот механизм используется почти во всех модулях фреймворка Spring, являясь фундаментом для построения более сложных механизмов.
Пару недель назад мы уже краем касались этой темы, когда рассматривали self-inject’ы и Transactional-аннотацию. Под этой аннотацией, как и под многими другими, как раз таки и скрывается механизм аспектно-ориентированного программирования.
Зачем нам нужно АОП? Данный функционал хорошо себя показывает в задачах, связанных с логированием или предоставлением доступов к каким-либо ресурсам. Чтобы не дублировать код наших логов по всему проекту, мы можем вынести это в одно место и вызывать (с помощью аспектов) перед выполнением метода или после. В случае предоставления доступов бывают ситуации, когда нам нужно проверить доступ к ресурсам исходя не только из токена (или любого другого ключа) пользователя, а из данных, которые находятся, например, в базе данных. Есть ли у пользователя X доступ к скачиванию этой фотографии или архива с документами?
Давайте попробуем разобраться на простом примере (примеры будут сразу в следующих постах). Для начала, в pom.xml, вы должны иметь следующие зависимости: spring-boot-starter-web, spring-boot-starter-aop. Это минимальный набор, чтобы начать изучать spring aop. Рассмотрим самописные аспекты по логированию какой-то информации сигнатуре метода и по доступу к файлу.
#rdclr_backend #java
Всем привет! С вами снова Андрей, java-разработчик. Мы продолжим говорить об экосистеме java и смежных вещах. Сегодня затронем АОП. Тема очень обширная, поэтому в этой мини-статье заденем минимальные основы.
В рамках Spring-фреймворка АОП является некой сквозной логикой, которую мы можем использовать в любом месте приложения, всего навсего повесив аннотацию (или с помощью xml-разметки). Также этот механизм используется почти во всех модулях фреймворка Spring, являясь фундаментом для построения более сложных механизмов.
Пару недель назад мы уже краем касались этой темы, когда рассматривали self-inject’ы и Transactional-аннотацию. Под этой аннотацией, как и под многими другими, как раз таки и скрывается механизм аспектно-ориентированного программирования.
Зачем нам нужно АОП? Данный функционал хорошо себя показывает в задачах, связанных с логированием или предоставлением доступов к каким-либо ресурсам. Чтобы не дублировать код наших логов по всему проекту, мы можем вынести это в одно место и вызывать (с помощью аспектов) перед выполнением метода или после. В случае предоставления доступов бывают ситуации, когда нам нужно проверить доступ к ресурсам исходя не только из токена (или любого другого ключа) пользователя, а из данных, которые находятся, например, в базе данных. Есть ли у пользователя X доступ к скачиванию этой фотографии или архива с документами?
Давайте попробуем разобраться на простом примере (примеры будут сразу в следующих постах). Для начала, в pom.xml, вы должны иметь следующие зависимости: spring-boot-starter-web, spring-boot-starter-aop. Это минимальный набор, чтобы начать изучать spring aop. Рассмотрим самописные аспекты по логированию какой-то информации сигнатуре метода и по доступу к файлу.
#rdclr_backend #java
Telegram
RDCLR.DEV
Ловушка @Transactional или использование Self-inject’ов
В бине имеется 2 метода: a() и b(), помеченных аннотацией @Transactional. Если мы из метода а() вызовем метод b() — как поведет себя транзакция метода b()?
Правильный ответ — транзакция метода b() не…
В бине имеется 2 метода: a() и b(), помеченных аннотацией @Transactional. Если мы из метода а() вызовем метод b() — как поведет себя транзакция метода b()?
Правильный ответ — транзакция метода b() не…
Аспект для логирования сигнатуры метода. Связан через аннотацию LogSomething (написана вручную, в ней нет ничего особенного)
#rdclr_backend #java
#rdclr_backend #java
Аспект для логирования сигнатуры метода. Связан через аннотацию CheckFileAccess (написана вручную, в ней тоже нет ничего особенного)
#rdclr_backend #java
#rdclr_backend #java
Сервис, где методы будут помечены созданными аннотациями LogSomething и CheckFileAccess
#rdclr_backend #java
#rdclr_backend #java
Spring framework: под капотом
До этого мы с вами разбирали основные инструменты фреймворка Spring, которые помогают сделать нашу разработку проще.
Настало время разобраться, как же работает та самая «магия» Спринга под капотом. С помощью каких инструментов создаются бины, инжект бинов, что такое в принципе понятие Бин. Весь процесс от запуска приложения, до его окончательного рабочего состояния. И в этом нам поможет довольно известный разработчик Евгений Борисов, который в своих лекциях посвящает нас в работу движка фреймворка на самом низком уровне. Для качественной разработки эти знания просто необходимы, поэтому на собеседованиях java-разработчиков довольно часто попадаются вопросы этой тематики.
У Евгения на ютубе имеется целый цикл лекций по Спрингу на самые разные темы. Предлагаю вам начать изучение с одной из самых популярных из его лекций — Spring-потрошитель. Не пугайтесь, что видео 2014 года: оно актуально и по сей день, ибо под капотом фреймворк почти не изменился.
Часть 1 https://youtu.be/BmBr5diz8WA
Часть 2 https://youtu.be/cou_qomYLNU
#rdclr_backend #java #read
До этого мы с вами разбирали основные инструменты фреймворка Spring, которые помогают сделать нашу разработку проще.
Настало время разобраться, как же работает та самая «магия» Спринга под капотом. С помощью каких инструментов создаются бины, инжект бинов, что такое в принципе понятие Бин. Весь процесс от запуска приложения, до его окончательного рабочего состояния. И в этом нам поможет довольно известный разработчик Евгений Борисов, который в своих лекциях посвящает нас в работу движка фреймворка на самом низком уровне. Для качественной разработки эти знания просто необходимы, поэтому на собеседованиях java-разработчиков довольно часто попадаются вопросы этой тематики.
У Евгения на ютубе имеется целый цикл лекций по Спрингу на самые разные темы. Предлагаю вам начать изучение с одной из самых популярных из его лекций — Spring-потрошитель. Не пугайтесь, что видео 2014 года: оно актуально и по сей день, ибо под капотом фреймворк почти не изменился.
Часть 1 https://youtu.be/BmBr5diz8WA
Часть 2 https://youtu.be/cou_qomYLNU
#rdclr_backend #java #read