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

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

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

🧬Система контроля версий. Де-факто индустриальный стандарт — это 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

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

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

Сколько нужно стендов/энвайроментов в Trunk Based Development подходе

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

🦄 Если у вас возник вопрос, при чем здесь единороги, смотрите предыдущий пост.

В зависимости от вашей философии разработки и готовности экспериментировать, правильным ответом может быть 2️⃣, 3️⃣ или 4️⃣.
Давайте рассмотрим каждый из них.

Но начнем с 1️⃣. Single Environment — вполне себе жизнеспособный подход. В Trunk Based Development основная ветка считается стабильной, новый функционал скрыт фича тогглами, поэтому ничего не мешает жить с одним окружением. При условии, если архитектура вашей системы позволяет гарантировать стабильность транк-веток репозиториев всех компонентов без интеграционных тестов между этими компонентами и без инструментов типа Terraform или Helm для управления инфраструктурой. Ну или у вас огромное количество времени и вычислительных можностей и внутри CI/CD пайплайна вы каждый раз поднимаете мини-энв. Поэтому от сферических единорожков перейдем к реальным. 🌈

2️⃣ окружения. Итак, нам нужно иметь возможность проверять изменения кода до того, как они попали в основную ветку. Очень простой рецепт — вешаем CI триггер на пуллреквесты.
Алгоритм следующий: разработчик создает свою короткоживущую веточку, делает изменения, тестирует их локально. Потом пушит и делает пуллреквест в основную. CI собирает компонент, делает статический анализ (линтер или SonarQube), прогоняет юнит тесты, упаковывает в докер и разворачивает на отдельном стенде (обычно мы называем этот стенд dev или sandbox, давайте и будем называть его песочницей). Тут же в пайплайне запускаются автотесты (для бэкенда достаточно API тестов, для фронтенда тестов в headless браузере). При этом на любом шаге, если что-то сломалось, пайплайн не завершится и песочнца будет сломана. Но откатиться до предыдущего состояния можно, просто сделав реверс пуллреквест.
Если все прошло успешно, это означает, что новые изменения не ломают предыдущей логики, зафиксированной тестами. Разработчик может протестировать новый функционал на стенде, и после этого отправить пуллреквест на ревью.
То есть на ревью попадает пуллреквест, который заведомо ничего не сломает. Поэтому ревьюеры могут сконцентрироваться на проверке бизнес-функционала, а не на отлове возможных несовместимостей. После ревью изменения мерджатся в основную ветку и проходят все те же шаги сборки и регрессии, но уже на втором, боевом стенде. С каждым изменением единорожек эволюционирует.

У предыдущего подхода есть минус. Он защищает нас от того, что сломается автоматизация инфраструктуры и бизнес логика. Но не защитит от некорректных данных в БД, а это иногда становится большой проблемой. В варианте с двумя окружениями второй, стабильный энв содержит и тестовые и продакшн данные. Чтобы физически изолировать их, можно добавить третий стенд. 3️⃣
Итак, первый стенд — sandbox, разработчики могут его ломать и экспериментировать еще до ревью
Второй — test, он содержит код, собранный из основных веток, но он предназначен только для тестирования нового функционала. Теоретически на нем можно сломать данные, тестируя какие-нибудь негативные сценарии (А что будет, если напоить единорога самогоном вместо утренней росы? 🤮)
Третий — prod, и там разворачиваются те же самые артефакты, что были собраны на предыдущем шаге. При этом хорошей практикой считается раскатывать сюда новую версию сервиса, как только она прошла авторегрессию на тесте. Мы все еще находимся в парадигме Continuous Deployment и Shift Right (см предыдущий пост), но тестовое окружение физически отделено от продакшена.

Какой подход вам нравится больше всего?
#rdclr_backend #rdclr_frontend #product

Отдельно рассмотрим вариант с 4️⃣ стендами.

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

Какая проблема возникает при отказе от Continuous Deployment? То, что нам приходится где-то замораживать версию продукта для стабилизации, но при этом мы не хотим останавливать разработку нового функционала. Поэтому можно использовать следующий поход:
sandbox и test остаются как и в предыдущем варианте — это инкубатор, где единорог постепенно эволюционирует.

Как только мы понимаем, что он достаточно хорош, нам приходится его клонировать, отсаживая в отдельный загончик — релизную ветку. Оттуда собираются артефакты на третий промежуточный стенд — stage. На нем происходит стабилизация, после чего единорожка выпускается на волю (на prod), а релизная ветка со всеми багфиксами тэгается, мерджится обратно в транк и закрывается. При этом основную ветку ничто не останавливает и она уходит вперед.

🐛 Если находится критический баг на продакшене, мы можем выпустить патч-релиз. Для этого мы просто восстанавливаем релизную ветку нужного сервиса из тэга и используем stage для новых изменений в нашем загончике, после чего он снова попадает на prod, а изменения тэгаются, мержатся в основную ветку, а патч-ветка закрывается.

При таком подходе мы все еще остаемся в парадигме Trunk Based Development, т.к. у нас
- одна основная ветка (trunk), 🦋
- короткоживущие фича ветки для эволюции (slfb),
- релизные ветки, которые живут только в период стабилизации,
- стабилизационные багфикс ветки, которые живут еще меньше, чем релизная

#rdclr_backend #rdclr_frontend #product

Ревью кода: кросс-ревью. Практики тим-лидов

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

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

Однако, мое мнение, что все вышеперечисленное абсолютно неверно и на всех своих проектах стараюсь вводить такую практику как кросс-ревью.

🦀 Кросс-ревью — это проверка кода всеми членами команды.

А теперь как в Турецком сериале: «Самое интересное в следующей серии» 😉

#teamlead #rdclr_backend #rdclr_frontend

Вы подумали это все? А вот и нет =)
👍🏻 При кросс-ревью нет нагрузки на отдельного разработчика (тим-лида), который один должен пересмотреть все ревью.

👎🏻 Однако бывают случаи, когда разработчики, увидев, что более опытный разраб поставил аппрув, даже не уделяют внимания просмотру.

🚨 На такой случай есть суперский лайфхак: будучи тимлидом или ведущим разработчиком, вы можете специально допустить несколько ошибок в ревью, дабы проверить, кто добросовестно просматривает ваш код.

Всем тем, кто поставил аппрув не глядя, следует в доступной форме объяснить важность данной церемонии и попросить больше так не делать. Пара повторных подобных проверок (можно подговорить еще кого-нибудь из команды) — и ваш код будет просматриваться детальнее, чем сумка на таможне.

📮 В ходе повествования я упирался в слово «код», но такая практика может быть использована в команде абсолютно любого направления. И важно добавить, что под словом «команда» подразумевается отдельное направление (бэк, фронт, qa, дизайн и тд).

Правила всего 2:
1) желание развиваться и делать вашу работу все лучше и лучше;
2) команда от 3х человек и более (в случае 2х человек, само наличие ревью уже превращается в кросс-ревью).

Надеюсь, у всех вас на проектах существует кросс-ревью и вы ему рады. 😀
#teamlead #rdclr_frontend #rdclr_backend

Что такое нейронные сети

Хотелось бы начать с краткого экскурса в нейронные сети. Открыв любой интернет источник, можно очень часто увидеть такую формулировку: «Искусственные нейронные сети — это вычислительные модели, вдохновленные человеческим мозгом».

🧠 Нейронные сети действительно напоминают мозг человека (животного), как минимум следующими признаками:
1) нейронная сеть получает знания посредством обучения;
2) знания нейронной сети — это хранилище сил межнейронных связей, также известных, как веса нейронной сети.

Любые алгоритмы разрабатываются с целью решения каких-то задач, нейронные сети не стали исключением. Они позволяют выполнять задачи по осмыслению данных, сохраняя при этом свои другие свойства.
Сейчас мы их разберем.
#rdclr_backend #NN

Нейронные сети и их задачи. 1 — Классификация
Разберем подробнее каждый из типов задач.

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

Одна из самых первых задач, с которой сталкивается человек, который только начал изучать нейронные сети — это определение того, что представлено на изображении: кошка или собака.🐕🐈‍⬛
Это накладывает определенные ограничения на обучающую выборку, так как каждый набор данных должен быть помечен. Пример задачи с кошками и собаками говорит, что абсолютно к каждому изображению должно быть пояснение. А именно, к какому классу относится данное изображение (кошка или собака).

Подход, когда заранее известны выходные данные нейронной сети, называется «контролируемое обучение», или «обучение с учителем».
#rdclr_backend #NN

Нейронные сети и их задачи. 2 и 3 — Кластеризация и Предиктивный анализ

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

🧐 Например, это может быть сравнение изображений или звуков, а также обнаружение аномалий. Для кластеризации крайне необходимо иметь большую выборку, ибо чем больше данных «прогонит» через себя нейронная сеть, тем точнее она будет.

💎 Предиктивный анализ
Предиктивный анализ по-другому часто называют задачей регрессии.

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

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

Дальше мы разберем популярные библиотеки и инструменты работы с нейтронными сетями. А пока — хорошего вечера! 🥟
#rdclr_backend #NN

Инструменты под python для разработки нейронных сетей
Сегодня хотелось бы поговорить об инструментах и библиотеках, которые помогут в разработке и описании нейронных сетей.

Подавляющая доля разработок в области нейронных сетей приходится на язык программирования python 🐍 , поэтому и рассматривать будем решения под этот язык программирования.

🌪 jupyter notebook — это мощный инструмент для разработки и представления data science проектов. Он способен хранить код, графики, изображения и формулы в одном месте.

💨 google colab — бесплатная облачная среда от компании Google, позволяющая работать с jupiter блокнотами. Данный сервис предоставляет 12 ГБ ОЗУ и сессии до 12 часов. Так же, как и у остальных продуктов данной компании, реализована возможность совместного использования.

#rdclr_backend #NN

Библиотеки для работы с нейронными сетями
Теперь рассмотрим основные библиотеки для построения и обучения нейронных сетей.

1. 🍏 TensorFlow — платформа с открытым исходным кодом, разработанная компанией Google для создания приложений глубокого обучения. Он также поддерживает традиционное машинное обучение.

Изначально TensorFlow разрабатывался для больших числовых вычислений без учета глубокого обучения. Однако, он оказался очень полезным и для разработки глубокого обучения, и поэтому Google открыл его исходный код.

2. 🍎 PyTorch — это библиотека машинного обучения, разработанная командой Facebook AI Reseach. Полностью основана на python и использующая мощность графических процессоров. Это также одна из предпочтительных исследовательских платформ глубокого обучения, созданная для обеспечения максимальной гибкости и скорости.

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

3. 🍐 Keras — это высокоуровневый API глубокого обучения. Keras относительно прост в освоении, так как предоставляет интерфейсы с высоким уровнем абстракции. Именно эту библиотеку рекомендуется начать изучать людям, которые только начинают освоение нейронных сетей.

P.S. В конце хотелось бы порекомендовать сайт, который будет полезен студентам и людям, работающим с нейронными сетями. Он позволяет строить базовые схемы нейронных сетей — alexlenail.me 🧩

#rdclr_backend #NN

Нейронные сети: принцип трансферного обучения
Одной из причин такого результата работы нейронной сети было то, что ей «не хватало» знаний о том, что изображено на конкретной картинке. Для того, чтобы исправить данную ситуацию, необходимо использовать уже готовое решение.

Transfer learning
♻️ Трансферное обучение — это повторное использование существующих моделей для решение новой задачи или проблемы.

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

☝🏻 Применяя трансферное обучение, можно добиться более высокой производительности, чем при обучении с небольшим объемом данных. Данный метод настолько распространен, потому что редко можно с нуля обучить модель задачам, связанным с обработкой изображений или с обработкой естественного языка.

🌗 Возвращаясь к задаче раскраски черно-белых изображений, одним из решений было использование предобученной нейронной сети для классификации изображений и объединение выхода данной нейронной сети с собственной нейронной сетью на определенном этапе ее работы. Это и позволило получать более приемлемые результаты.
#rdclr_backend #NN

Микросервсиная архитекутера

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

Можно взять и разбить приложение на микросервисы. Но это не даст гарантий, что проект будет легко поддерживать и масшабировать, гибко изменять код — рано или поздно вы столкнетесь с проблемами. Для решения таких проблем как раз и появились различные принципы программирования — SOLID, DRY, KISS, CQRS.

#rdclr_backend #Java

Друзья, привет! На связи всё так же я, Павел, Java-разработчик Red Collar. 🤝

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

В общем, встречайте первую статью в Telegraph! Собрал здесь все принципы SOLID с примерами, подсветил сложные моменты, про всё рассказал подробно. 🦾

Читайте тут: https://telegra.ph/Open-closed--princip-otkrytosti--zakrytosti-05-16


#rdclr_backend #Java

Друзья, всем привет! Это вновь я, Java-разработчик Red Collar Павел.
Продолжаю тестить Телеграф и рассказывать вам о фишках разработки. На этот раз — о Spring DATA JDBC.

Это классная альтернатива JPA, но у неё, конечно, есть свои подводные камни.

Читайте о них здесь: https://telegra.ph/Spring-DATA-JDBC-05-24

#rdclr_backend #Java