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

К счастью для нас, сфера разработки не исключение. Уже не первый год энтузиаст 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

Trunk Based Development

Итак, TBD. Модель управления ветками в репозитории, переросшая в методологию и становящаяся все популярнее в последние годы. Сразу оговорюсь, всю теорию вы можете прочитать на официальном сайте комьюнити https://trunkbaseddevelopment.com, там все описано очень (местами даже слишком) подробно.

По определению, Trunk Based Development — это модель управления ветками, когда у вас есть только одна долгоживущая ветвь кода (trunk, main, master, название неважно) и вы всячески сопротивляетесь соблазнам завести вторую. А соблазнов много:
🥎 различия в окружениях (кластеризованные и сингл нод базы данных, разный уровень доступа, дебаг режим на лоу стендах и т.д.);
⚾️ большие изменения функционала, когда кажется, что проще поступиться обратной совместимостью, запилить и накатить новые версии на все компоненты сразу;
🎾 страх менеджмента, привыкшего работать с монолитными системами десятилетиями.

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

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

Именно этот принцип — развивать проект небольшими инкрементальными изменениями — и лежит в основе разработки. Для этого используются следующие техники:

⚽️ Branch By Abstraction
🏀 Short Living Feature Branches
🏈 Continuous Deployment
🏉 Feature Toggling
🏐 Shift Right

Про них мы подробно поговорим в следующем посте.

#rdclr_backend #rdclr_frontend #product #read

Trunk Based Development: техники и определения

Давайте разберем термины из предыдущего поста

Branch By Abstraction — пожалуй, краеугольный камень TBD. Попробуем объяснить эту технику на единорожках. У нас есть обычная лошадка 🐴, но мы понимаем, что вообще-то нам нужен единорог. 🦄

Справка: единороги отличаются от лошадей рогом, магией и тем, что их тошнит радугой. При этом магия без рога не работает.

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

Стандартный вариант. Делаем единорожью ветку в репозитории и начинаем разрабатывать в ней. Понимаем, что единорогу нужен усиленный лоб для крепления рога, докидываем его. Команда, занимающаяся магией, форкается от нашей ветки, потому что у них зависимость на рог. Через месяц наш единорог готов, но сразу смержить его в релизную ветку мы не можем, потому что за это время на лбу лошадке нарисовали звездочку к новому году и она несовместима с усиленным лбом. Единорожья ветка жила слишком долго и разъехалась с основной. Чиним конфликты, пару недель на стабилизацию и наш единорог в продакшене. Упс, его тошнит северным сиянием.

Подход Branch By Abstraction так же подразумевает ветвление функционала, но делается это не сопровождением разного кода в репозитории, а введением уровня абстракции в той же кодовой базе. Берем лошадку и эволюционируем ее. Усиливаем лобик, что позволит быстро прикрутить рог, но не будет заметно для пользователя. Добавляем генератор радуги, который пока не включается. Получается, что мы наращиваем функционал, но он какое-то время находится в отдельной логической, а не физической ветке.

Чтобы обезопасить себя и скрыть от пользователя, что с его поняшкой что-то происходит, можно использовать Feature Toggles — механизм управления фича флагами. Этот именно тот переключатель, который выбирает нужную логическую ветку и включает у пони режим единорога.
Есть готовые решения, такие как LaunchDarkly или Unleash, но можно при желании реализовать их самостоятельно.

Например, если надеть специальную перчатку и потрепать за носик, у лошадки включится режим генерации радуги.🌈 Тестировщик сможет включать для себя режим единорога, а обычный пользователь ничего не заметит. При этом это одна и та же лошадка, любое изменение сразу эволюционирует ее. Получается, что фаза тестирования в стандартном код-тест-деплой-релиз у нас смещается вправо (код-деплой-тест-релиз), поэтому такой подход называется Shift Right.

После контроля качества нового функционала, можно открыть его бета-тестерам, а потом какому-нибудь проценту пользователей, чтобы изучить их реакцию. Можно поэкспериментировать с формой рожек, чтобы понять, какой из них больше нравится (AB тесты в таком подходе работают из коробки). Так как передеплоивать ничего не нужно, наша лошадка всегда может вернуться в предыдущее состояние, просто поменяв конфигурацию.
В этот период у нас получается единорог Шредингера: он и есть и нет, все это управляется конфигурацией. Определение релиза фичи при этом тоже меняется — это момент, когда 100% пользователей получат своего единорожка. 🦄

Каждое эволюционное изменение должно быть небольшим по объему и делаться в короткоживущей ветке (Short Living Feature Branch). Такая ветка живет от силы пару дней, быстро ревьюится и объединяется с основной. Кодревью при этом быстр и несложен из-за небольшого объема изменений.

Любое изменение кода сразу же эволюционирует нашу лошадку (раскатывается на продакшн). Такой подход называется Continuos Deployment, не путать с Continuous Delivery, когда мы просто собираем артефакт, но нигде его не устанавливаем. Страшно?

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

#rdclr_backend #rdclr_frontend #product