Суть в том, что существует «старый добрый» способ описания хранилища состояний при помощи обычного react-redux.
Проблема старого способа в том, что приходилось писать очень много шаблонного кода (на жаргоне — бойлерплейта).
За это его постоянно ругали разработчики всех мастей.

Но затем вышел Redux Toolkit, который создан специально для решения данной проблемы.
Мы можем создавать все те же хранилища состояний, но при этом писать гораздо меньше кода, по сравнению с react-redux.

Однако реалии таковы, что это все же новый инструмент со своими нюансами, поэтому редко кто-то перепрыгивает
с react-redux на ReduxToolKit прямо на ходу.

#rdclr_frontend #React #product #read #library #redux

Генерация клиента из OpenAPI

Если ваш бэкенд использует Swagger (OpenApi 3.0) для генерации документации, то вы можете знатно упростить себе жизнь на крупном проекте.
Однако это упрощение идет дальше типичного чтения документации. Прямо сейчас вы можете генерировать Клиент, Сервер и Типы данных для TypeScript из файла openapi schema.

🎁 Пакет для генерации Клиента: https://github.com/OpenAPITools/openapi-generator-cli

Установка:
yarn add @openapitools/openapi-generator-cli
либо
npm install @openapitools/openapi-generator-cli

1️⃣ Предварительно создайте папку для результатов генерации и файл конфигурации.

2️⃣ После установки вам нужно создать файл конфигурации openapitools.json для генератора и папку для хранения результатов
openapitools.json:

{
 "$schema": "node_modules/@openapitools/openapi-generator-cli/config.schema.json",
 "spaces": 2,
 "generator-cli": {
  "version": "5.1.1",
  "generators": {
   "v1": {
    "generatorName": "typescript-fetch",
    "inputSpec": "link_or_path_to_yours_openapi_schema",
    "output": "path_to_yours_output",
    "additionalProperties": {
     "supportsES6": true,
     "sagasAndRecords": true,
     "typescriptThreePlus": true,
     "withInterfaces": true,
     "withoutRuntimeChecks": false
    }
   }
  }
 }
}


```3️⃣ Затем запустите процесс генерации командой:
```yarn openapi-generator-cli generate

4️⃣ В результате мы получим:
generated-api/models — здесь хранятся типы данных и функции для трансформации данных бэк->фронт фронт->бэк
generated-api/apis — здесь вы найдете сгрупированные по эндпоинтам классы для запросов к API

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

🦷 Если вам необходимы только типы для TypeScript, может подойти пакет: https://github.com/drwpow/openapi-typescript

Полный список генераторов вы найдёте здесь: https://openapi-generator.tech/docs/generators

#rdclr_frontend #React #product #read #library

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

К счастью для нас, сфера разработки не исключение. Уже не первый год энтузиаст Eric Wastl разрабатывает адвент-календарь, суть которого в решении серии небольших программных головоломок различного уровня сложности. Каждый день, начиная с 1 декабря и заканчивая Новым годом, вам предоставляется новая задача, которую вы можете решить на вашем любимом языке программирования. Само собой начальные задачи не представляют какой-либо сложности и решаются довольно просто, но чем ближе 31 декабря, тем всё больше усилий от вас будет требовать этот мини-квест.

Предлагаю вам проверить свои силы и присоединиться к этому чиловому соревнованию!
Ссылка на календарь: https://adventofcode.com/

#read

АОП. Аспектно-ориентированное программирование

Всем привет! С вами снова Андрей, java-разработчик. Мы продолжим говорить об экосистеме java и смежных вещах. Сегодня затронем АОП. Тема очень обширная, поэтому в этой мини-статье заденем минимальные основы.

В рамках Spring-фреймворка АОП является некой сквозной логикой, которую мы можем использовать в любом месте приложения, всего навсего повесив аннотацию (или с помощью xml-разметки). Также этот механизм используется почти во всех модулях фреймворка Spring, являясь фундаментом для построения более сложных механизмов.

Пару недель назад мы уже краем касались этой темы, когда рассматривали self-inject’ы и Transactional-аннотацию. Под этой аннотацией, как и под многими другими, как раз таки и скрывается механизм аспектно-ориентированного программирования.

Зачем нам нужно АОП? Данный функционал хорошо себя показывает в задачах, связанных с логированием или предоставлением доступов к каким-либо ресурсам. Чтобы не дублировать код наших логов по всему проекту, мы можем вынести это в одно место и вызывать (с помощью аспектов) перед выполнением метода или после. В случае предоставления доступов бывают ситуации, когда нам нужно проверить доступ к ресурсам исходя не только из токена (или любого другого ключа) пользователя, а из данных, которые находятся, например, в базе данных. Есть ли у пользователя X доступ к скачиванию этой фотографии или архива с документами?

Давайте попробуем разобраться на простом примере (примеры будут сразу в следующих постах). Для начала, в pom.xml, вы должны иметь следующие зависимости: spring-boot-starter-web, spring-boot-starter-aop. Это минимальный набор, чтобы начать изучать spring aop. Рассмотрим самописные аспекты по логированию какой-то информации сигнатуре метода и по доступу к файлу.

#rdclr_backend #java

Аспект для логирования сигнатуры метода. Связан через аннотацию LogSomething (написана вручную, в ней нет ничего особенного)

#rdclr_backend #java

Аспект для логирования сигнатуры метода. Связан через аннотацию CheckFileAccess (написана вручную, в ней тоже нет ничего особенного)

#rdclr_backend #java

Сервис, где методы будут помечены созданными аннотациями LogSomething и CheckFileAccess

#rdclr_backend #java

Spring framework: под капотом

До этого мы с вами разбирали основные инструменты фреймворка Spring, которые помогают сделать нашу разработку проще.

Настало время разобраться, как же работает та самая «магия» Спринга под капотом. С помощью каких инструментов создаются бины, инжект бинов, что такое в принципе понятие Бин. Весь процесс от запуска приложения, до его окончательного рабочего состояния. И в этом нам поможет довольно известный разработчик Евгений Борисов, который в своих лекциях посвящает нас в работу движка фреймворка на самом низком уровне. Для качественной разработки эти знания просто необходимы, поэтому на собеседованиях java-разработчиков довольно часто попадаются вопросы этой тематики.

У Евгения на ютубе имеется целый цикл лекций по Спрингу на самые разные темы. Предлагаю вам начать изучение с одной из самых популярных из его лекций — Spring-потрошитель. Не пугайтесь, что видео 2014 года: оно актуально и по сей день, ибо под капотом фреймворк почти не изменился.

Часть 1 https://youtu.be/BmBr5diz8WA
Часть 2 https://youtu.be/cou_qomYLNU

#rdclr_backend #java #read

Java. Какую версию выбрать?

Начиная с 2017 года релизная политика версий java в корне поменялась. Вместо продолжительных застоев в несколько лет с накоплением большого количества фич, было принято решение перейти на релизы каждые полгода, выпуская маленькими партиями новый функционал. Если раньше можно было выбрать просто 8 версию, которая являлась LTS, и не прогадать с выбором, то теперь версий стало куда больше (на текущий момент уже 17). В связи с этим у многих новичков встает очевидный вопрос: как выбрать версию джавы? Может я просто возьму последнюю и все? Не совсем так, давайте разбираться.

Основным провайдером java является компания Oracle, которая предоставляет нам 2 типа jdk: OpenJdk и OracleJdk. Основное их отличие в том, что OracleJdk является платной и содержит в себе поддержку от самой компании (вы сможете им позвонить или написать письмо), если у вас возникнут какие-то проблемы. Такой вариант обычно необходим только очень большим продуктам и компаниям, поэтому мы его отбрасываем и будем пользоваться бесплатной версией. Скачать её можно тут – http://jdk.java.net

Теперь про версионность. Основной выбор всегда падает на LTS (Long Time Support) версии java, так как из-за долгой поддержки и исправления багов эти версии наиболее стабильны и преподносят меньшее число сюрпризов в продакшне. На текущий момент в мире все еще преобладает использование java 8, которая вышла в 2014 году. В основном это связано с тем, что на этой версии уже написаны крайне массивные продукты, которые потребуют больших трудозатрат и средств для переноса на более новые версии. А так как эти огромные продукты продолжают жить, то продолжает жить и java 8.

Для новых решений зачастую берется просто последняя LTS версия джавы. Да, вот так вот просто! До недавнего времени это была java 11, на текущий момент java 17. Но так как 17 версия все еще очень молодая (ей всего пару месяцев), я бы рекомендовал вам пока что выбрать 11 версию для изучения, так как не все еще основные инструменты и библиотеки успели переехать на новый релиз.

Также предлагаю вам посмотреть наикрутейшее выступление Тагира Валеева на JockerConf про то, как менялась java под капотом с 9 по 14 версию. https://youtu.be/5Y0Alqb9H_I

#rdclr_backend #java #read

Java. Какую версию выбрать? Часть 2

Помимо основного вендора java в лице Oracle, существуют и другие выпуски от других компаний. Давайте их рассмотрим:

🍒 1) AdoptOpenJDK
Проект, поддерживаемый сообществом. Команда выпускает билды, основанные на OpenJDK, отличие лишь в более долгосрочной поддержке. Команда занимается только билдами и не выпускает патчи для openjdk

🍩 2) Red Hat OpenJDK
Основана на версиях сборки OpenJDK, является коммерческим продуктом с платной поддержкой. В своих версиях компания нацелена на исправления безопасности в OpenJDK. В прошлом Red Hat отвечали за security-апдейты Java 6 и 7.

🫀 3) Azul Zulu
Основана на версиях OpenJDK, поставляется как open-source, но так же имеется — по сравнению с OracleJDK — более длительная коммерческая поддержка java 9, 13, 15.

🩱4) IBM JDK
Компании IBM требовалось написать свой собственный JIT-компилятор и свою собственную JVM, чтобы программы, написанные на java, могли запускаться на их мейнфреймах и при этом не заставлять разработчиков изучать новую java. Поэтому эти версии, с точки зрения программиста, практически идентичны.

🥡 5) Amazon Correto
Бесплатная версия сборки OpenJDK с долгосрочной поддержкой. Данная версия нацелена на максимальную производительность в облачных вычислениях. Так же Амазон каждый квартал выпускает багфиксы, что позволяет более оперативно устранять уязвимости.

🛺 6) Liberica JDK
Отечественная версия java, основанной также на OpenJDK. Плюсы перед OpenJDK все те же, что и других вендоров. Она бесплатна, более продолжительная коммерческая поддержка, частые выпуски обновлений безопасности, маленький размер контейнера (минимальный — всего 43.5мб).

Еще существенным плюсом является тот факт, что Liberica JDK Pro была внесена в реестр российского ПО. Это означает расширение диапазона применения Liberica JDK в государственных информационных системах, где крайне важна защита ПО от внешних факторов (например, санкций).

#rdclr_backend #java #read

Привет! Я Сережа, и я технический директор в Red Collar

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

Каждую среду наша команда разработки тусит и слушает доклад на какую-нибудь интересную тему. Сегодня Марина рассказывает про информационную безопасность

Разбираем софт для командной разработки

Любой большой проект — это не только идея и код, который эту идею реализует. Проект — это команда, а команда — это постоянное общение и софт, помогающий быть на одной волне 🏄‍♂️

🧬Система контроля версий. Де-факто индустриальный стандарт — это Git, но можно встретить компании и проекты, которые используют Mercurial, SVN и более экзотические штуки. Чистый гит не очень удобен, поэтому фактически в разработке используют готовые системы управления репозиториями: gitlab, github, bitbucket.

📌 Вторая необходимая составляющая — трекер задач. Это место, где описываются и распределяются задачи, планируются спринты, отслеживается прогресс. Самое популярное решение здесь Jira, но есть и другие, например, youtrack или trello.

🗒 База знаний проекта — проектная вики, где документируются принятые решения, идеи, юзкейсы, архитектурные диаграммы. Из примеров — confluence, outline и, как ни странно, система README файлов.

🛠 CI/CD движки, собирающие из вашего кода докер образы, библиотеки, пакеты и разворачивающие их на окружениях. Jenkins, Teamcity, Gitlab pipelines, Bitbucket pipelines.

🎁 Хранилища артефактов. Npm, maven репозитории, регистры Docker образов. Из того, что первое приходит в голову — это Artefactory, Verdaccio, Nexus.

💣 Многие вендоры предлагают коробочные решения, объединяющие все или часть нужного функционала. Как правило, такие решения имеют очень хорошие интеграции: по каждой задаче можно увидеть все изменения кода, тесты, собранные артефакты, связанные документы. Это очень удобно для навигации и аналитики. Примеры — Atlassian Suite (Jira, Confluence, Bitbucket), Azure DevOps. Недавно появился еще один игрок — Jetbrains Space, который мы используем с лета в пилотном режиме на части проектов.

#rdclr_frontend #rdclr_backend #rdclr_QA

Мы узнали кучу всего интересного об

⚔️ OWASP
⚔️ Penetration тестирование
⚔️ OSINT
⚔️ Сколько стоит безопасность
⚔️ Как вырастить культуру безопасности в разработке софта

А вам интересно про это узнать? Скоро Рин будет дежурить по каналу и обо всем расскажет подробно ^_^

Для чего нужна система контроля версий?

🦕 Когда-то, давным-давно, программы писались в текстовых файлах и при командной разработке все изменения кода сливались вручную. И было это даже не в эру динозавров: еще в начале двухтысячных годов существовали проекты, где код объединяли с помощью diff разных директорий.

🔧 Но появлялись и наращивали функционал системы версионирования. В 1998 году в SVN появилась поддержка веток кода и их объединения, в 2005 году вышел всеми любимый Git.

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

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

Но, прежде чем переходить к подробному разбору бестпрактисов, давайте проведем пару опросов.

#rdclr_backend #rdclr_frontend

Сколько репозиториев нужно проекту

На самом деле, все ответы из опроса выше были верными, просто тот или иной подход применим в зависимости от ваших задач. 🥰

🥑 Монорепа хороша для прототипов, PoC (Proof of Concept, когда нужно быстро собрать решение на коленке и убедиться, что технология работает, как ожидалось) и, например, конкурсно-тендерных историй, когда небольшое по объему решение нужно отдать на аудит. В этом случае нет никакого смысла плодить репозитоиии, достаточно обойтись одним.

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

🍇 Самым универсальным является подход, когда мы создаем по одному репозиторию на компонент. Примем, что компонент — это артефакт, то есть нечто, что можно собрать и использовать (устанавливать, деплоить) независимо от других частей системы. Это может быть Docker образ, общая библиотека, npm пакет, jar файл, скрипт для настройки инфраструктуры. Мы помним, что современные системы управления репозиториями умеют запускать CI/CD пайплайны (сборку, публикацию, деплой). И очень удобно иметь один репозиторий, триггерящий один сценарий сборки, который собирает один артефакт.

🥒 А самый популярный вариант в опросе — «зависит от архитектуры проекта и релизных процессов» — на самом деле покрывает предыдущие три и ничего конкретного не говорит

#rdclr_backend #rdclr_frontend #product

Сколько веток должно быть в репозитории

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

Давайте разберем ответы из нашего опроса с конца:

👩‍🔧 По количеству разработчиков + 1.
Наверное, тут есть логика, что каждый девелопер работает в своей ветке и время от времени все сливают свои изменения в одну общую. Но почему бы не создавать новую ветку под задачу и потом закрывать ее после мерджа, переходя к следующей? Непонятно. Вариант синтетический, и, на мой вкус, не очень осмысленный.

🖥 По числу стендов и окружений.
Этот подход действительно много где применяется. Его концепция в том, что у нас есть одна основная ветка с кодом и по ветке на стенды: тест, стейдж, прод и т.д. Ветки, ассоциированные со стендами, содержат специфические настройки окружений. Например, разработческая и тестовая ветки могут ходить на единичный инстанс БД, а стейдж и продакшн поддерживать архитектуру мастер-реплика. Минус здесь в том, что, по сути, на каждый стенд вы деплоите разный код, собранный специально для этого стенда. И гарантировать одинаковое поведение системы невозможно.

🔗 Две ветки — develop и master.
Это отсылка к широко известному GitFlow со всеми его плюсами и минусами.
Вообще говоря, с момента появления GitFlow прошло больше десяти лет, а с тех пор многое изменилось. Появилась концепция микросервисов, Docker, клауды и инструменты Infrastructure as Code. Ну и родился он в недрах Linux сообщества для координации работы большого количества программистов, пишущих монолитный продукт со множеством инсталляций в условиях, когда нужно поддерживать и развивать несколько версий. Если ваш продукт подходит под это описание, то... ну почему бы и нет. Но если у вас микросервисы и по одному репозиторию на компонент, как описано в предыдущем посте, то развлечения с ветками, разъехавшимися версиями на окружениях, поиском коммитов в ветках, мерджами и конфликт резолвингом вам гарантированы.

❓ Почему так? Потому что, если у вас несколько долгоживущих веток, рано или поздно они они начинают различаться все сильнее и сильнее. Радикальный способ избавиться от этой проблемы —>

🦄 Одна долгоживущая ветка.
С непривычки звучит странно, но все чаще современные методологии разработки строятся на этом принципе. В следующем посте мы поговорим об одной из самых популярных — философии Trunk Based Development.

Keep tuned.

#rdclr_backend #rdclr_frontend #product