Всем привет!
Сегодня хотел бы поднять такую тему - что должно быть в проекте сервиса (в исходниках)?
Кроме собственно кода и файлов с настройками.
1) readme.md
Наличие: обязательно.
Содержимое: описание проекта, его идентификатор (для DevOps pipeline или в вашем реестре сервисов), описание вариантов сборки (отладка, запуск модульных и интеграционных тестов, чистовая сборка), структура каталогов, возможно важные особенности сборки
2) .gitignore
Наличие: обязательно
3) test.http
Наличие: крайне желательно
Содержимое: список URL для отладки на localhost в формате, который понимает IntelliJ IDEA
4) IDEA run configuration
Наличие: крайне желательно
Да, конфигурации тоже можно сохранять. Особенно полезны для больших проектов, допускающих отладку отдельных частей для скорости.
5) скрипты и настройки CI
Наличие: крайне желательно
Часто скрипты меняются вместе с кодом, лучше держать их вместе
6) todo.md
Наличие: желательно
Содержимое: техдолг с точки зрения разработчиков сервиса. Я специально делаю акцент на происхождение, т.к. еще есть внешний техдолг от архитекторов, сопровождения, ИБ, его обычно заводят в JIRA. Почему бы и внутренний техдолг не завести в JIRA? Можно, но есть два риска: если работа идет не по Scrum - задача потеряется в недрах системы, если работа идет по Scrum - слишком рьяный Scrum мастер в рамках гигиены JIRA может настоять на удалении задачи как непонятной\неактуальной. Храня же техдолг вместе с кодом мы можем свободно уточнять формулировки, разбивать на более мелкие задачи для последующего переноса в JIRA с взятием в ближайший спринт.
7) Maven или Gradle wrapper
Наличие: желательно, чтобы не зависеть от наличия утилиты в среде сборки
8) профили checkstyle и ему подобных утилит статического анализа кода
Наличие: возможно, если требуется подстройка для вашего сервиса
9) статическая часть папки .idea
Наличие: возможно по договоренности с командой
10) settings.xml для Maven
Наличие: возможно если они меняются от проекта к проекту
11) документация, естественно через автогенерацию
Наличие: возможно, особенно для библиотек
P.S. Еще может возникнуть вопрос про схемы API - их лучше держать отдельно, чтобы физически разделить интерфейс и реализацию.
#sources
Сегодня хотел бы поднять такую тему - что должно быть в проекте сервиса (в исходниках)?
Кроме собственно кода и файлов с настройками.
1) readme.md
Наличие: обязательно.
Содержимое: описание проекта, его идентификатор (для DevOps pipeline или в вашем реестре сервисов), описание вариантов сборки (отладка, запуск модульных и интеграционных тестов, чистовая сборка), структура каталогов, возможно важные особенности сборки
2) .gitignore
Наличие: обязательно
3) test.http
Наличие: крайне желательно
Содержимое: список URL для отладки на localhost в формате, который понимает IntelliJ IDEA
4) IDEA run configuration
Наличие: крайне желательно
Да, конфигурации тоже можно сохранять. Особенно полезны для больших проектов, допускающих отладку отдельных частей для скорости.
5) скрипты и настройки CI
Наличие: крайне желательно
Часто скрипты меняются вместе с кодом, лучше держать их вместе
6) todo.md
Наличие: желательно
Содержимое: техдолг с точки зрения разработчиков сервиса. Я специально делаю акцент на происхождение, т.к. еще есть внешний техдолг от архитекторов, сопровождения, ИБ, его обычно заводят в JIRA. Почему бы и внутренний техдолг не завести в JIRA? Можно, но есть два риска: если работа идет не по Scrum - задача потеряется в недрах системы, если работа идет по Scrum - слишком рьяный Scrum мастер в рамках гигиены JIRA может настоять на удалении задачи как непонятной\неактуальной. Храня же техдолг вместе с кодом мы можем свободно уточнять формулировки, разбивать на более мелкие задачи для последующего переноса в JIRA с взятием в ближайший спринт.
7) Maven или Gradle wrapper
Наличие: желательно, чтобы не зависеть от наличия утилиты в среде сборки
8) профили checkstyle и ему подобных утилит статического анализа кода
Наличие: возможно, если требуется подстройка для вашего сервиса
9) статическая часть папки .idea
Наличие: возможно по договоренности с командой
10) settings.xml для Maven
Наличие: возможно если они меняются от проекта к проекту
11) документация, естественно через автогенерацию
Наличие: возможно, особенно для библиотек
P.S. Еще может возникнуть вопрос про схемы API - их лучше держать отдельно, чтобы физически разделить интерфейс и реализацию.
#sources
Всем привет!
Хорошая подробная статья про кодировки в Java и что изменилось в Java 18 https://habr.com/ru/companies/jugru/articles/709952/
Еще порадовало, что кто-то заморочился и сделал вот такой навигатор: https://habr.com/ru/articles/147843/ )))
А вывод следующий: в существующих Java сервисах надо явно указывать кодировку, как я и говорил ранее: https://t.me/javaKotlinDevOps/193 В новых написанных на Java 18+ в большинстве случаев можно положится на кодировку по умолчанию - UTF-8. Если конечно вы не храните данные в другой кодировке) Или не работаете с Windows и ее консолью и файловой системой. Или кто-то в вашей команде
не проводит отладку на Windows.
#java #encoding
Хорошая подробная статья про кодировки в Java и что изменилось в Java 18 https://habr.com/ru/companies/jugru/articles/709952/
Еще порадовало, что кто-то заморочился и сделал вот такой навигатор: https://habr.com/ru/articles/147843/ )))
А вывод следующий: в существующих Java сервисах надо явно указывать кодировку, как я и говорил ранее: https://t.me/javaKotlinDevOps/193 В новых написанных на Java 18+ в большинстве случаев можно положится на кодировку по умолчанию - UTF-8. Если конечно вы не храните данные в другой кодировке) Или не работаете с Windows и ее консолью и файловой системой. Или кто-то в вашей команде
не проводит отладку на Windows.
#java #encoding
Хабр
JEP-400 или UTF-8 РєРѕРґРёСЂРѕРІРєР° РїРѕ умолчанию
Не прошло и пяти лет, как в Java 18 докатилось небольшое, но очень ожидаемое и обсуждаемое изменение: теперь во всех стандартных API используется UTF-8 кодировка по умолчанию. Это изменение, которое...
Всем привет!
Я уже писал о проблеме интероперабельности Kotlin-Java касающейся null safety - https://t.me/javaKotlinDevOps/190
Есть и еще одна, коллега столкнулся с ней недавно.
В Kotlin четко разделяет изменяемые и неизменяемые коллекции на уровне типов, по умолчанию предлагая делать их неизменяемыми.
В Java наоборот - по умолчанию все коллекции изменяемые, хотя неизменяемые создать тоже можно, например, Collections.unmodifiableXXX, но это не единственный способ.
Итого: предположу, что в Kotlin условно 90% коллекций немодифицируемые, в Java - наоборот 90% модифицируемые.
Что же будет при передаче коллекции из Kotlin в Java?
Да, хорошая практика независимо от языка - не менять передаваемые в метод параметры. Но эта практика не стимулируется к использованию Java.
Да, иммутабельность можно проверить, но делается это довольно криво и я подозреваю делается редко: https://ru.stackoverflow.com/questions/608545/collections-unmodifiable-как-определить
Отсюда получаем, что с большой вероятностью возможна ошибка UnsupportedOperationException на вставке в эти коллекции в Java.
#java #kotlin
Я уже писал о проблеме интероперабельности Kotlin-Java касающейся null safety - https://t.me/javaKotlinDevOps/190
Есть и еще одна, коллега столкнулся с ней недавно.
В Kotlin четко разделяет изменяемые и неизменяемые коллекции на уровне типов, по умолчанию предлагая делать их неизменяемыми.
В Java наоборот - по умолчанию все коллекции изменяемые, хотя неизменяемые создать тоже можно, например, Collections.unmodifiableXXX, но это не единственный способ.
Итого: предположу, что в Kotlin условно 90% коллекций немодифицируемые, в Java - наоборот 90% модифицируемые.
Что же будет при передаче коллекции из Kotlin в Java?
Да, хорошая практика независимо от языка - не менять передаваемые в метод параметры. Но эта практика не стимулируется к использованию Java.
Да, иммутабельность можно проверить, но делается это довольно криво и я подозреваю делается редко: https://ru.stackoverflow.com/questions/608545/collections-unmodifiable-как-определить
Отсюда получаем, что с большой вероятностью возможна ошибка UnsupportedOperationException на вставке в эти коллекции в Java.
#java #kotlin
Telegram
(java || kotlin) && devOps
Всем привет!
Сегодня пост о крутой фиче Kotlin, которая решила одну важную проблему. И добавила другую)
Я о Null safety.
Суть ее в том, что в Kotlin любой тип представлен в двух ипостасях - одна может содержать null значения, другая - нет.
String - не может…
Сегодня пост о крутой фиче Kotlin, которая решила одну важную проблему. И добавила другую)
Я о Null safety.
Суть ее в том, что в Kotlin любой тип представлен в двух ипостасях - одна может содержать null значения, другая - нет.
String - не может…
Всем привет!
Проверяемые исключения - еще одна вещь, которой отличаются Java и Kotlin.
В Kotlin их нет, и вот тут описано почему https://kotlinlang.ru/docs/reference/exceptions.html
Там же есть ссылка на диалог таких известных людей как Bruce Eckel и Anders Hejlsberg на эту тему https://www.artima.com/articles/the-trouble-with-checked-exceptions
Вот тут есть его русский перевод https://habr.com/ru/articles/221723/
В целом соглашусь с основным аргументом авторов: с ростом кодовой базы - а тут важно помнить, что кроме кода сервиса мы еще используем кучу библиотек включая вездесущий Spring Framework - проверяемых исключений становится слишком много. А их выборочная обработка в бизнес приложении, которое активно использует внешние библиотеки, часто не нужна. Т.е. есть цепочка вызова из к примеру 10 сервисов, а обработка исключений - в одном из них, максимум в двух. В остальных случаях их приходится пробрасывать. Отсюда приходим к throws Exception. А это явный антипаттерн.
Следовательно, в большинстве случаев вред от проверяемых исключений перевешивает пользу. Хотя идея - если рассматривать ее именно как идею - красивая: объявляем в API не только типы входящих и исходящих параметров, но и потенциально возможные ошибки. Вот только удобной реализации пока никто не придумал)))
#java #kotlin #exceptions #checked_exceptions
Проверяемые исключения - еще одна вещь, которой отличаются Java и Kotlin.
В Kotlin их нет, и вот тут описано почему https://kotlinlang.ru/docs/reference/exceptions.html
Там же есть ссылка на диалог таких известных людей как Bruce Eckel и Anders Hejlsberg на эту тему https://www.artima.com/articles/the-trouble-with-checked-exceptions
Вот тут есть его русский перевод https://habr.com/ru/articles/221723/
В целом соглашусь с основным аргументом авторов: с ростом кодовой базы - а тут важно помнить, что кроме кода сервиса мы еще используем кучу библиотек включая вездесущий Spring Framework - проверяемых исключений становится слишком много. А их выборочная обработка в бизнес приложении, которое активно использует внешние библиотеки, часто не нужна. Т.е. есть цепочка вызова из к примеру 10 сервисов, а обработка исключений - в одном из них, максимум в двух. В остальных случаях их приходится пробрасывать. Отсюда приходим к throws Exception. А это явный антипаттерн.
Следовательно, в большинстве случаев вред от проверяемых исключений перевешивает пользу. Хотя идея - если рассматривать ее именно как идею - красивая: объявляем в API не только типы входящих и исходящих параметров, но и потенциально возможные ошибки. Вот только удобной реализации пока никто не придумал)))
#java #kotlin #exceptions #checked_exceptions
Что делаете с проверяемыми исключениями из Java Core и внешних библиотек?
Anonymous Poll
38%
Честно пробрасываю все
54%
Сразу же ловлю и обрабатываю
23%
throws Exception скрипя зубами)
Всем привет!
Прочитал статью о том, как можно обойтись без OpenAPI при взаимодействии по REST API https://habr.com/ru/companies/magnit/articles/763952
Для тех кому лень читать - там предлагается использовать Java DTO. В целом подход интересный и рабочий. Но есть нюанс. Схема OpenAPI - внешний артефакт. Он лежит либо в git репозитории или API Studio от Swagger. Код по нему генерируется в каталоге сборки. Забыть обновится при выходе новой версии сложнее как раз из-за чёткого понимания того, что API - внешнее. Хотя конечно же можно )
Другое дело Java API. Это про сути ещё одна из десятков библиотек, подключенных к проекту. Версию библиотеки мы фиксируем как это принято при управлении зависимостями. Забыть о том, что это внешнее API, гораздо легче.
Я сейчас говорю не только про кейс, описанный в статье. Ещё есть вариант обмена данными через распределенный кэш, путём сериализации Java POJO объектов, встречал его на практике. А самый яркий антипаттерн при похожем подходе - обмен данными через БД. В этом случае как правило обмениваются скриптами БД, а не классами. Но идея похожа - зачем нам лишняя сущность в виде схемы, лишние преобразования, когда уже есть код. Или уже есть таблица в БД. Конечно, интеграция через БД стала антипаттерном в том числе и потому, что БД - это не только схема, но ещё и транзакции, блокировки, триггеры. Но главную причину я озвучил выше - каждая команда будет считать базу своей внутренней, забывая, что это API. Проблема психологическая, не техническая.
Итого: подход интересный, имеет права на жизнь (я про обмен jar-никами, не про интеграцию через БД), но требует дисциплины. Или автоматизации на этапе CI, позволяющей не надеятся на человеческий фактор.
P.S. Как говорится, не OpenAPI единым - есть ещё Protobuf, GraphQL, xsd наконец. Но самый распространённый - OpenAPI, поэтому везде упоминается он.
#api #OpenAPI #integration
Прочитал статью о том, как можно обойтись без OpenAPI при взаимодействии по REST API https://habr.com/ru/companies/magnit/articles/763952
Для тех кому лень читать - там предлагается использовать Java DTO. В целом подход интересный и рабочий. Но есть нюанс. Схема OpenAPI - внешний артефакт. Он лежит либо в git репозитории или API Studio от Swagger. Код по нему генерируется в каталоге сборки. Забыть обновится при выходе новой версии сложнее как раз из-за чёткого понимания того, что API - внешнее. Хотя конечно же можно )
Другое дело Java API. Это про сути ещё одна из десятков библиотек, подключенных к проекту. Версию библиотеки мы фиксируем как это принято при управлении зависимостями. Забыть о том, что это внешнее API, гораздо легче.
Я сейчас говорю не только про кейс, описанный в статье. Ещё есть вариант обмена данными через распределенный кэш, путём сериализации Java POJO объектов, встречал его на практике. А самый яркий антипаттерн при похожем подходе - обмен данными через БД. В этом случае как правило обмениваются скриптами БД, а не классами. Но идея похожа - зачем нам лишняя сущность в виде схемы, лишние преобразования, когда уже есть код. Или уже есть таблица в БД. Конечно, интеграция через БД стала антипаттерном в том числе и потому, что БД - это не только схема, но ещё и транзакции, блокировки, триггеры. Но главную причину я озвучил выше - каждая команда будет считать базу своей внутренней, забывая, что это API. Проблема психологическая, не техническая.
Итого: подход интересный, имеет права на жизнь (я про обмен jar-никами, не про интеграцию через БД), но требует дисциплины. Или автоматизации на этапе CI, позволяющей не надеятся на человеческий фактор.
P.S. Как говорится, не OpenAPI единым - есть ещё Protobuf, GraphQL, xsd наконец. Но самый распространённый - OpenAPI, поэтому везде упоминается он.
#api #OpenAPI #integration
Хабр
Объектно-ориентированный подход к созданию REST-клиентов, или возможна ли жизнь без Open API
Как-то в общении с моим другом-разработчиком из одной крупной софтверной компании у нас зашёл разговор о взаимодействии распределённых команд. В его компании было множество достаточно изолированных...
Всем привет!
Я уже писал про один особенный класс в Java - enum - https://t.me/javaKotlinDevOps/14
Вот ещё один - массив.
1) да, массив - тоже класс, хранится в куче, наследуется от Object.
2) Главная особенность этого объекта - его класс не определен заранее, JVM создаёт его динамически. Соответственно, его исходники нельзя посмотреть и от него нельзя наследоваться. Имя у него строится по принципу [X, где X - кодирует тип элементов массива, скобка - это скобка) Например, [I для массива int.
3) размер массива как известно фиксируется при создании и его можно получить вызвав array.length. Но интересно, что это не поле класса, значение хранится в заголовке объекта
4) исходя из сказанного выше массив - это особый класс, плохо вписывающийся в систему классов Java. Для него даже пришлось ввести 2 специальные инструкции байткода - для создания и получения длины
5) массив используется под капотом у ArrayList. Если массив статичен, то ArrayList - динамически растёт по мере его заполнения. Ну и является «нормальным» классом)
6) элементы массива расположены последовательно друг за другом в heap, что сильно ускоряет поиск\вставку по номеру элемента
7) массивы ковариантны и поэтому не типобезопасны. Пример кода, который скомпилируется, но упадет в runtime:
Integer[] a1 = new Integer[10];
Object[] a2 = a1;
a2[0] = "Привет ArrayStoreException"
ArrayList является generic и поэтому инвариантен - аналогичный код не скомпилируется:
List<Integer> a1 = new ArrayList()
List<Object> a2 = a1;
8) массивы могут содержать как примитивы, так и объекты, что выгодно отличает их от коллекций. Поэтому основное применение массива, которое я вижу, работа с большим количеством примитивных типов - это будет эффективно с точки зрения памяти и отсутствия операций boxing/unboxing. Зачем нужны массивы объектов - для использования в ArrayList, других применений не могу придумать)
P.S. На написание поста меня подтолкнула эта статья - https://habr.com/ru/articles/753638/, но она для совсем джунов-джунов, решил расширить и повысить концентрацию полезной информации)))
#java #arrays
Я уже писал про один особенный класс в Java - enum - https://t.me/javaKotlinDevOps/14
Вот ещё один - массив.
1) да, массив - тоже класс, хранится в куче, наследуется от Object.
2) Главная особенность этого объекта - его класс не определен заранее, JVM создаёт его динамически. Соответственно, его исходники нельзя посмотреть и от него нельзя наследоваться. Имя у него строится по принципу [X, где X - кодирует тип элементов массива, скобка - это скобка) Например, [I для массива int.
3) размер массива как известно фиксируется при создании и его можно получить вызвав array.length. Но интересно, что это не поле класса, значение хранится в заголовке объекта
4) исходя из сказанного выше массив - это особый класс, плохо вписывающийся в систему классов Java. Для него даже пришлось ввести 2 специальные инструкции байткода - для создания и получения длины
5) массив используется под капотом у ArrayList. Если массив статичен, то ArrayList - динамически растёт по мере его заполнения. Ну и является «нормальным» классом)
6) элементы массива расположены последовательно друг за другом в heap, что сильно ускоряет поиск\вставку по номеру элемента
7) массивы ковариантны и поэтому не типобезопасны. Пример кода, который скомпилируется, но упадет в runtime:
Integer[] a1 = new Integer[10];
Object[] a2 = a1;
a2[0] = "Привет ArrayStoreException"
ArrayList является generic и поэтому инвариантен - аналогичный код не скомпилируется:
List<Integer> a1 = new ArrayList()
List<Object> a2 = a1;
8) массивы могут содержать как примитивы, так и объекты, что выгодно отличает их от коллекций. Поэтому основное применение массива, которое я вижу, работа с большим количеством примитивных типов - это будет эффективно с точки зрения памяти и отсутствия операций boxing/unboxing. Зачем нужны массивы объектов - для использования в ArrayList, других применений не могу придумать)
P.S. На написание поста меня подтолкнула эта статья - https://habr.com/ru/articles/753638/, но она для совсем джунов-джунов, решил расширить и повысить концентрацию полезной информации)))
#java #arrays
Telegram
(java || kotlin) && devOps
Всем привет!
Хочу рассказать про ряд неочевидных особенностей enum в Java.
Поехали!
1) enum - это полноценный класс, у него могут быть поля, методы, обычные и статические
2) любой enum неявно (!) расширяет абстрактный класс Enum, поэтому наследовать enum…
Хочу рассказать про ряд неочевидных особенностей enum в Java.
Поехали!
1) enum - это полноценный класс, у него могут быть поля, методы, обычные и статические
2) любой enum неявно (!) расширяет абстрактный класс Enum, поэтому наследовать enum…
Всем привет!
Среди первых постов этого канала был пост про k8s - для чего он нужен https://t.me/javaKotlinDevOps/6
Но я забыл рассказать про Service Mesh - что же она добавляет к k8s. Если вы не понимаете, что за Service Mesh такой - самой известной реализацией является Istio https://istio.io/latest/docs/ На его примере хочу рассказать про Service Mesh.
Начал искать материалы и сразу наткнулся на серию отличных статей:
https://habr.com/ru/companies/flant/articles/438426/
https://habr.com/ru/companies/flant/articles/569612/
https://habr.com/ru/companies/oleg-bunin/articles/726958/
Рекомендую их почитать, там есть и про устройство Istio на сетевом уровне, и про решаемые им задачи, и про вносимые данной технологией риски.
Для тех, кому лень читать поработаю продвинутой версией Yandex GPT.
Основные "плюшки" Istio:
1) возможность аутентификации и авторизации запросов как по адресам, url-ам, так и с помощью OAuth
2) продвинутые возможности балансировки - например, привязка клиента к конкретному серверу или геопривязка: перенаправление только на экземпляры сервиса, находящиеся в том же гео-кластере
3) реализация паттерна Circuit Breaker, повторов и настройка таймаутов для запросов
4) продвинутые возможности маршрутизации: по URL и http заголовкам
5) реализация канареечного развертывания и зеркалирования траффика
6) TLS Termination и Origination - снятие и добавление TLS шифрования на входе\выходе из namespace, что позволяет полностью переложить работу с сертификатами с разработки на сопровождение
Вывод следующий: Service Mesh - новый уровень абстракции поверх обычного облака (k8s). Да, он добавляет сложность, особенно в части сопровождения. Вносит небольшие задержки, которые в определенных случаях могут быть критичны. Требует ресурсов, что также может быть важно. Но если его "плюшки" вам полезны - оно того стоит)
#istio #k8s #service_mesh #cloud
Среди первых постов этого канала был пост про k8s - для чего он нужен https://t.me/javaKotlinDevOps/6
Но я забыл рассказать про Service Mesh - что же она добавляет к k8s. Если вы не понимаете, что за Service Mesh такой - самой известной реализацией является Istio https://istio.io/latest/docs/ На его примере хочу рассказать про Service Mesh.
Начал искать материалы и сразу наткнулся на серию отличных статей:
https://habr.com/ru/companies/flant/articles/438426/
https://habr.com/ru/companies/flant/articles/569612/
https://habr.com/ru/companies/oleg-bunin/articles/726958/
Рекомендую их почитать, там есть и про устройство Istio на сетевом уровне, и про решаемые им задачи, и про вносимые данной технологией риски.
Для тех, кому лень читать поработаю продвинутой версией Yandex GPT.
Основные "плюшки" Istio:
1) возможность аутентификации и авторизации запросов как по адресам, url-ам, так и с помощью OAuth
2) продвинутые возможности балансировки - например, привязка клиента к конкретному серверу или геопривязка: перенаправление только на экземпляры сервиса, находящиеся в том же гео-кластере
3) реализация паттерна Circuit Breaker, повторов и настройка таймаутов для запросов
4) продвинутые возможности маршрутизации: по URL и http заголовкам
5) реализация канареечного развертывания и зеркалирования траффика
6) TLS Termination и Origination - снятие и добавление TLS шифрования на входе\выходе из namespace, что позволяет полностью переложить работу с сертификатами с разработки на сопровождение
Вывод следующий: Service Mesh - новый уровень абстракции поверх обычного облака (k8s). Да, он добавляет сложность, особенно в части сопровождения. Вносит небольшие задержки, которые в определенных случаях могут быть критичны. Требует ресурсов, что также может быть важно. Но если его "плюшки" вам полезны - оно того стоит)
#istio #k8s #service_mesh #cloud
Telegram
(java || kotlin) && devOps
Чем kubernetes, он же k8s лучше контейнера сервлетов или сервера приложений.
Во-первых под капотом k8s лежит Docker, а значит мы получаем все его плюшки. Не зря k8s называют оркестратором контейнеров. Чем занимается оркестратор?
1) планированиеи ресурсов.…
Во-первых под капотом k8s лежит Docker, а значит мы получаем все его плюшки. Не зря k8s называют оркестратором контейнеров. Чем занимается оркестратор?
1) планированиеи ресурсов.…
Всем привет!
К вопросу о кратком пересказе текста. Как вы наверное знаете, недавно такую фичу выкатил Яндекс - назвал ее YandexGPT.
Вот пример краткого пересказа двух статей из предыдущего поста.
Istio в разрезе: что умеет и не умеет самый популярный Service Mesh (обзор и видео доклада) / Хабр
• Istio - это система управления Service Mesh, которая позволяет реализовать разные паттерны по управлению TCP-трафиком в проекте.
• Istio предоставляет набор интерфейсов для настройки и управления компонентами Service Mesh.
• Istio может влиять на надежность приложения, но требует правильной настройки и использования.
• Istio также влияет на latency, безопасность и масштабирование.
• В Istio можно использовать протокол Delta xDS для сокращения нагрузки на Control Plane и сеть.
• Ожидается, что Ambient Mesh, новая функция Istio, упростит обновления и снизит нагрузку на Control Plane.
https://300.ya.ru/PxCuGmdO
Что ждать от внедрения Istio? (обзор и видео доклада) / Хабр
• Istio - частный случай «сервисной сетки» (Service Mesh), понятия, о котором наверняка все слышали.
• Istio влияет на трафик, возможности для его мониторинга, безопасность mTLS.
• Istio имеет свой декларативный язык для управления сетью.
• Istio интегрируется с сторонними инструментами для мониторинга, например, с дашбордом Kiali.
• Istio предоставляет возможности для внедрения трассировки на основе Jaeger.
• Безопасность mTLS в Istio считается безопасной.
• Вопросы к Istio: влияние на приложение, кластер, observability, безопасность mTLS.
https://300.ya.ru/4cNaxU0s
Что хочется отметить:
1) ИИ не умеет структурировать тезисы, идет сверху вниз
2) ИИ не умеет выбирать ключевые фичи и делать акценты
3) "Безопасность ... считается безопасной"
P.S. Что касается п.3 - а может ИИ уже научился шутить и нам стоит начинать бояться?)
#ai #yandexgpt #yandex
К вопросу о кратком пересказе текста. Как вы наверное знаете, недавно такую фичу выкатил Яндекс - назвал ее YandexGPT.
Вот пример краткого пересказа двух статей из предыдущего поста.
Istio в разрезе: что умеет и не умеет самый популярный Service Mesh (обзор и видео доклада) / Хабр
• Istio - это система управления Service Mesh, которая позволяет реализовать разные паттерны по управлению TCP-трафиком в проекте.
• Istio предоставляет набор интерфейсов для настройки и управления компонентами Service Mesh.
• Istio может влиять на надежность приложения, но требует правильной настройки и использования.
• Istio также влияет на latency, безопасность и масштабирование.
• В Istio можно использовать протокол Delta xDS для сокращения нагрузки на Control Plane и сеть.
• Ожидается, что Ambient Mesh, новая функция Istio, упростит обновления и снизит нагрузку на Control Plane.
https://300.ya.ru/PxCuGmdO
Что ждать от внедрения Istio? (обзор и видео доклада) / Хабр
• Istio - частный случай «сервисной сетки» (Service Mesh), понятия, о котором наверняка все слышали.
• Istio влияет на трафик, возможности для его мониторинга, безопасность mTLS.
• Istio имеет свой декларативный язык для управления сетью.
• Istio интегрируется с сторонними инструментами для мониторинга, например, с дашбордом Kiali.
• Istio предоставляет возможности для внедрения трассировки на основе Jaeger.
• Безопасность mTLS в Istio считается безопасной.
• Вопросы к Istio: влияние на приложение, кластер, observability, безопасность mTLS.
https://300.ya.ru/4cNaxU0s
Что хочется отметить:
1) ИИ не умеет структурировать тезисы, идет сверху вниз
2) ИИ не умеет выбирать ключевые фичи и делать акценты
3) "Безопасность ... считается безопасной"
P.S. Что касается п.3 - а может ИИ уже научился шутить и нам стоит начинать бояться?)
#ai #yandexgpt #yandex
300.ya.ru
Пересказ YandexGPT: Istio в разрезе: что умеет и не умеет самый популярный Service Mesh (обзор и видео доклада)
• Istio - это система управления Service Mesh, которая позволяет реализовать разные паттерны по управлению TCP-трафиком в проекте.
• Istio предоставляет набор интерфейсов для настройки и управления компонентами Service Mesh.
• Istio может влиять на надежность…
• Istio предоставляет набор интерфейсов для настройки и управления компонентами Service Mesh.
• Istio может влиять на надежность…
Всем привет!
Прочитал книгу Лемер "Масштабируемый рефакторинг". В целом понравилась, с важным дисклеймером.
С одной стороны основные мысли в книге вполне себе "капитанские". С другой - о них очень легко забыть)))
Еще важный момент - большинство правил из книжки применимо для скажем так большого рефакторинга: затрагивающего платформенный сервис, от которого зависят множество команд, ядро монолита, схему БД или что-то подобное. Если нужно отрефакторить метод или класс - данные рекомендации скорее всего будут излишними.
Тезисы:
1) т.к. рефакторинг займет длительное время - нужен план. План позволит:
а) видеть весь объем работ и правильно оценить: хватит ли выделенного бизнесом времени
б) найти забытые задачи либо самостоятельно - анализируя план - либо с помощью смежных команд, опубликовав его
2) рефакторинг нужно делать для кода в вашей области ответственности. Если за код отвечает другая - не надо его трогать без согласования
3) нужно понять - не является ли код deprecated или неиспользуемым. Часто код забывают удалять, все его использование ограничивается модульными тестами
4) нужно изучить - почему код стал таким. Зачем?
а) возможно выяснится, что "это не баг, а фича"
б) когда станет понятно, на почему возникли те или иные компромиссы в коде - это изменит отношение к коду. Все же приятнее улучшать сложный legacy код, а не "переписывать этот го..код"
5) нужно ответить себе на вопрос - почему код нужно рефакторить именно сейчас. А возможные ответы на этот вопрос приводят к необходимости метрик для бизнеса, о которых я уже писал https://t.me/javaKotlinDevOps/197
6) важно собрать команду с двумя типами участников: full time разработчики и эксперты. Для этого нужно договориться с руководителями о их полном или частичном подключении к задаче рефакторинга. Искать стоит людей, либо заинтересованных в результате рефакторинга, либо тех, кому надоела рутина и хочется, что-то поменять
7) нужен канал или страничка, где регулярно будут публиковаться прогресс рефакторинга. В случае, если прогресс будет - это может мотивировать на подключение к рефакторингу новых участников. Прогресс нужно сопоставлять с планом, при необходимости вносить корректировки. Также нужен митап или чат, где заинтересованные лица смогут задать вопросы.
8) прогресс нужно контролировать еще потому, что ближе к концу, когда основные изменения уже сделаны, есть риск снижения темпов. Из-за выгорания или расслабления - ведь основные изменения уже сделаны. Что тут можно сделать:
а) собираться командой в неформальной обстановке
б) рассказывать о своих достижениях для вливания "новой крови"
9) после окончания рефакторинга важно проконтролировать, что все потребители знают об изменениях и либо уже используют их, либо запланировали обновление. Речь может идти о переходе на новое API, новый фреймворк, новый DevOps, новую версию библиотеки. Для ускорения процесса перехода нужны:
а) рассылка
б) демонстрация
в) инструкция
г) чат, куда можно задать вопросы
д) возможно регулярный митап для ответов на сложные вопросы
#books #refactoring #book_review
Прочитал книгу Лемер "Масштабируемый рефакторинг". В целом понравилась, с важным дисклеймером.
С одной стороны основные мысли в книге вполне себе "капитанские". С другой - о них очень легко забыть)))
Еще важный момент - большинство правил из книжки применимо для скажем так большого рефакторинга: затрагивающего платформенный сервис, от которого зависят множество команд, ядро монолита, схему БД или что-то подобное. Если нужно отрефакторить метод или класс - данные рекомендации скорее всего будут излишними.
Тезисы:
1) т.к. рефакторинг займет длительное время - нужен план. План позволит:
а) видеть весь объем работ и правильно оценить: хватит ли выделенного бизнесом времени
б) найти забытые задачи либо самостоятельно - анализируя план - либо с помощью смежных команд, опубликовав его
2) рефакторинг нужно делать для кода в вашей области ответственности. Если за код отвечает другая - не надо его трогать без согласования
3) нужно понять - не является ли код deprecated или неиспользуемым. Часто код забывают удалять, все его использование ограничивается модульными тестами
4) нужно изучить - почему код стал таким. Зачем?
а) возможно выяснится, что "это не баг, а фича"
б) когда станет понятно, на почему возникли те или иные компромиссы в коде - это изменит отношение к коду. Все же приятнее улучшать сложный legacy код, а не "переписывать этот го..код"
5) нужно ответить себе на вопрос - почему код нужно рефакторить именно сейчас. А возможные ответы на этот вопрос приводят к необходимости метрик для бизнеса, о которых я уже писал https://t.me/javaKotlinDevOps/197
6) важно собрать команду с двумя типами участников: full time разработчики и эксперты. Для этого нужно договориться с руководителями о их полном или частичном подключении к задаче рефакторинга. Искать стоит людей, либо заинтересованных в результате рефакторинга, либо тех, кому надоела рутина и хочется, что-то поменять
7) нужен канал или страничка, где регулярно будут публиковаться прогресс рефакторинга. В случае, если прогресс будет - это может мотивировать на подключение к рефакторингу новых участников. Прогресс нужно сопоставлять с планом, при необходимости вносить корректировки. Также нужен митап или чат, где заинтересованные лица смогут задать вопросы.
8) прогресс нужно контролировать еще потому, что ближе к концу, когда основные изменения уже сделаны, есть риск снижения темпов. Из-за выгорания или расслабления - ведь основные изменения уже сделаны. Что тут можно сделать:
а) собираться командой в неформальной обстановке
б) рассказывать о своих достижениях для вливания "новой крови"
9) после окончания рефакторинга важно проконтролировать, что все потребители знают об изменениях и либо уже используют их, либо запланировали обновление. Речь может идти о переходе на новое API, новый фреймворк, новый DevOps, новую версию библиотеки. Для ускорения процесса перехода нужны:
а) рассылка
б) демонстрация
в) инструкция
г) чат, куда можно задать вопросы
д) возможно регулярный митап для ответов на сложные вопросы
#books #refactoring #book_review
Telegram
(java || kotlin) && devOps
Всем привет!
Я уже писал о важности рефакторинга.
Но как оценить, что рефакторинг достиг своих целей?
Можно экспертно. Но не всегда этот вариант годится для обоснования времени на рефакторинг у бизнеса.
Можно ли как-то подтвердить эффект цифрами?
Самый простой…
Я уже писал о важности рефакторинга.
Но как оценить, что рефакторинг достиг своих целей?
Можно экспертно. Но не всегда этот вариант годится для обоснования времени на рефакторинг у бизнеса.
Можно ли как-то подтвердить эффект цифрами?
Самый простой…
Всем привет!
Сегодня хочу поднять вопрос анемичной доменной модели. Давно холиварные вопросы не поднимал)
Одним из первых это понятие ввел Мартин Фаулер, см. https://martinfowler.com/bliki/AnemicDomainModel.html
Анемичной модели противопоставляется т.наз. "богатая" или, как я бы ее назвал, полноценная доменная модель.
В чем разница?
В анемичной доменной модели объекты по сути аналогичны DTO, их можно реализовать в виде Java records или Kotlin value object.
В полноценной - в объектах кроме данных есть бизнес-логика.
Вот аргументы сторонников полноценной модели:
https://www.baeldung.com/java-anemic-vs-rich-domain-objects
https://www.youtube.com/watch?v=lfdAwl3-X_c - особенно рекомендую, Егор как всегда подходит к теме "с огоньком")
Вот - сторонников анемичной модели: https://habr.com/ru/articles/346016/
Я в этом споре все же склоняюсь к полноценной модели.
Т.к. доменный объект - это не DTO, он должен содержать нечто большее. А именно - бизнес-логику. А вынося логику в отдельные сервисы легко так сильно ее размазать по коду, что это приведет к дублированию и ухудшению читаемости.
Более того: если модель становится анемичной - это может быть признаком, что модель не нужна, сервис является простым и можно вполне себе работать с DTO.
Особенно актуальна "богатая" доменная модель, если вы пытаетесь следовать практике DDD - Domain Driven Design. Собственно, ее автор, Эрик Эванс, сторонник этого подхода.
Да и есть смотреть определение класса в ООП - это не просто хранилище данных. Объект - это отражение сущности из реального мира. А в реальном мире объекты - кот, автомобиль, заказ - являются не только набором характеристик, но и могут что-то делать)
Но есть один нюанс.
Если логика не требует данных, не содержащихся в объекте - ей место в этом объекте.
Если требует данных извне, но не вызывает методы внешних объектов - аналогично.
А вот дальше простые правила заканчиваются и решения от сервиса к сервису могут отличаться. Как минимум стоит принять во внимание принцип SOLID, удобство переиспользования кода и удобство тестирования.
Да, и точно не стоит запихивать в модель инфраструктурный код - деление приложения на уровни никто не отменял.
Идея в том, что не надо боятся добавлять методы в объекты доменной модели. Более того, при проектировании стоит изначально думать о том, какими будут эти объекты.
Что касается нарушения принципов S и I из SOLID.
Не надо относится к этим принципам догматично. Если так делать - то у нас в итоге будет куча DTO с парой полей, куча интерфейсов с одним методом и взрыв мозга у людей, которые попытаются вникнуть в этом код с нуля) Важен баланс.
#anemic-vs-rich-domain-objects #holy_war #solid #oop
Сегодня хочу поднять вопрос анемичной доменной модели. Давно холиварные вопросы не поднимал)
Одним из первых это понятие ввел Мартин Фаулер, см. https://martinfowler.com/bliki/AnemicDomainModel.html
Анемичной модели противопоставляется т.наз. "богатая" или, как я бы ее назвал, полноценная доменная модель.
В чем разница?
В анемичной доменной модели объекты по сути аналогичны DTO, их можно реализовать в виде Java records или Kotlin value object.
В полноценной - в объектах кроме данных есть бизнес-логика.
Вот аргументы сторонников полноценной модели:
https://www.baeldung.com/java-anemic-vs-rich-domain-objects
https://www.youtube.com/watch?v=lfdAwl3-X_c - особенно рекомендую, Егор как всегда подходит к теме "с огоньком")
Вот - сторонников анемичной модели: https://habr.com/ru/articles/346016/
Я в этом споре все же склоняюсь к полноценной модели.
Т.к. доменный объект - это не DTO, он должен содержать нечто большее. А именно - бизнес-логику. А вынося логику в отдельные сервисы легко так сильно ее размазать по коду, что это приведет к дублированию и ухудшению читаемости.
Более того: если модель становится анемичной - это может быть признаком, что модель не нужна, сервис является простым и можно вполне себе работать с DTO.
Особенно актуальна "богатая" доменная модель, если вы пытаетесь следовать практике DDD - Domain Driven Design. Собственно, ее автор, Эрик Эванс, сторонник этого подхода.
Да и есть смотреть определение класса в ООП - это не просто хранилище данных. Объект - это отражение сущности из реального мира. А в реальном мире объекты - кот, автомобиль, заказ - являются не только набором характеристик, но и могут что-то делать)
Но есть один нюанс.
Если логика не требует данных, не содержащихся в объекте - ей место в этом объекте.
Если требует данных извне, но не вызывает методы внешних объектов - аналогично.
А вот дальше простые правила заканчиваются и решения от сервиса к сервису могут отличаться. Как минимум стоит принять во внимание принцип SOLID, удобство переиспользования кода и удобство тестирования.
Да, и точно не стоит запихивать в модель инфраструктурный код - деление приложения на уровни никто не отменял.
Идея в том, что не надо боятся добавлять методы в объекты доменной модели. Более того, при проектировании стоит изначально думать о том, какими будут эти объекты.
Что касается нарушения принципов S и I из SOLID.
Не надо относится к этим принципам догматично. Если так делать - то у нас в итоге будет куча DTO с парой полей, куча интерфейсов с одним методом и взрыв мозга у людей, которые попытаются вникнуть в этом код с нуля) Важен баланс.
#anemic-vs-rich-domain-objects #holy_war #solid #oop
martinfowler.com
bliki: Anemic Domain Model
If you use an object-oriented domain model, and you don't put behavior in your objects, you're missing out on most of the benefits of that pattern.
Всем привет!
Сегодня пятница, поговорим немного о магии.
Что я считаю одним из самых плохих качеств разработчика - веру в магию.
Симптомы магического мышления: фразы типа "ну вроде починил", "ну вроде работает". Или хаотичный перебор настроек в надежде, что все заработает. Или нежелание что-то менять в коде, из-за боязни поломать.
У любой проблемы при разработке ПО есть причины. Иногда они очевидны, иногда нужно потратить дни или недели, чтобы понять - почему оно так работает.
Бывает так, что не хватает времени, чтобы разобраться в причинах. Бывает так, что корни проблемы лежат в области, где не хватает компетенции - СУБД, внешняя система, pipeline. Это нужно понимать и признавать. Решение - искать специалиста или просить больше времени на разбор. Четыре лайфхака по самостоятельному разбору проблем:
1) посмотреть исходный код проблемного компонента, даже если он не ваш
2) погуглить)))
3) внимательнее читать логи. Часто вижу, что первая подозрительная запись в логах останавливает поиск. А если промотать еще десяток строк - лежит нормальное описание ошибки.
4) разбить проблему на части, т.к. часто самые загадочные случаи - это следствие череды ошибок.
Ну и прекрасная иллюстрация того, что любая магия имеет объяснение - вот эта статья: https://habr.com/ru/articles/759344/
#dev
Сегодня пятница, поговорим немного о магии.
Что я считаю одним из самых плохих качеств разработчика - веру в магию.
Симптомы магического мышления: фразы типа "ну вроде починил", "ну вроде работает". Или хаотичный перебор настроек в надежде, что все заработает. Или нежелание что-то менять в коде, из-за боязни поломать.
У любой проблемы при разработке ПО есть причины. Иногда они очевидны, иногда нужно потратить дни или недели, чтобы понять - почему оно так работает.
Бывает так, что не хватает времени, чтобы разобраться в причинах. Бывает так, что корни проблемы лежат в области, где не хватает компетенции - СУБД, внешняя система, pipeline. Это нужно понимать и признавать. Решение - искать специалиста или просить больше времени на разбор. Четыре лайфхака по самостоятельному разбору проблем:
1) посмотреть исходный код проблемного компонента, даже если он не ваш
2) погуглить)))
3) внимательнее читать логи. Часто вижу, что первая подозрительная запись в логах останавливает поиск. А если промотать еще десяток строк - лежит нормальное описание ошибки.
4) разбить проблему на части, т.к. часто самые загадочные случаи - это следствие череды ошибок.
Ну и прекрасная иллюстрация того, что любая магия имеет объяснение - вот эта статья: https://habr.com/ru/articles/759344/
#dev
Хабр
Высокие технологии или дешевые фокусы с двойным дном
Отлаживал я как-то тесты и параллельно размышлял о null-safety. Звезды сошлись и родилась довольно странная идея - замокать null . Искушения программиста смотрящего на Mockito.when().thenReturn() Ниже...
Всем привет!
Те, кто читал книжку Чистый код Мартина думаю помнят, что переменные должны иметь говорящие имена для повышения читаемости кода. Да и не только там эта мысль проходит. Я двумя руками за, писал уже об этом на канале.
Теперь внимание, вопрос - а можно ли тогда использовать переменные типа i или j в циклах? Откуда вообще взялись i и j, почему не a, b?
https://stackoverflow.com/questions/4137785/why-are-variables-i-and-j-used-for-counters
#java #math
Те, кто читал книжку Чистый код Мартина думаю помнят, что переменные должны иметь говорящие имена для повышения читаемости кода. Да и не только там эта мысль проходит. Я двумя руками за, писал уже об этом на канале.
Теперь внимание, вопрос - а можно ли тогда использовать переменные типа i или j в циклах? Откуда вообще взялись i и j, почему не a, b?
https://stackoverflow.com/questions/4137785/why-are-variables-i-and-j-used-for-counters
#java #math
Stack Overflow
Why are variables "i" and "j" used for counters?
I know this might seem like an absolutely silly question to ask, yet I am too curious not to ask...
Why did "i" and "j" become THE variables to use as counters in most control structures?
Although
Why did "i" and "j" become THE variables to use as counters in most control structures?
Although
Всем привет!
Что включает в себя понятие объекта?
1) объект может иметь данные
2) данные объекта можно менять
3) объект может иметь поведение - методы
4) от класса объекта можно наследоваться
5) объектов одного класса может быть несколько
6) каждый объект уникален - находится в heap по своему адресу. Т.е. имеет identity
Можно ли отобрать у объекта что-то из вышеперечисленного в Java?
1) final class - запрещаем наследование
2) sealed class - если полный запрет нам не подходит, то ограничиваем наследование https://habr.com/ru/companies/otus/articles/720044/
3) final поля - запрещаем менять данные класса после создания объекта - иммутабельность
4) records - запрещаем методы и изменение полей https://habr.com/ru/articles/487308/ Основое применение - DTO, где есть только данные и их нежелательно менять.
5) lambda - можно рассматривать как объект-функцию без данных, хотя технически это не так - JVM под капотом транслирует ее в статический метод https://javadungeon.wordpress.com/2017/08/02/java-8-lambdas-under-the-hood/
6) object в Kotlin - синлетона на уровне языка в Java нет, но такую конструкцию сделали в Kotlin
7) value class - еще не реализованная в Java концепция, которая по сути добавляет в язык что-то среднее между примитивным типом и объектом. Т.е. у нас будет объект, но в плане занимаемой памяти он будет почти также эффективен, как и примитив. Что важно: т.к. это объект - его можно будет использовать в generics. Ура-ура!. Детали: https://www.baeldung.com/java-valhalla-project Но ничего не бывает бесплатно - у такого объекта не будет identity, т.е. два объекта с одинаковыми полями считаются одинаковыми. Также, как это сейчас происходит с примитивными типами. Да, для объектов это уже сейчас можно реализовать на уровне кода. А тут идея сделать тоже самое на уровне JVM. Т.е. JVM может (обязана?) оставить один экземпляр для всех одинаковых объектов. Причем так, как это сделано сейчас со строками - вариант не очень, т.к. остается "дыра" с конструктором, который по определению всегда создает новый объект. Т.е. для value class нельзя использовать публичный конструктор, нужен какой-то фабричный метод - как элемент языка. Примеры, когда это полезно: те же классы-обвертки для чисел или географические объекты.
#java #oop #kotlin
Что включает в себя понятие объекта?
1) объект может иметь данные
2) данные объекта можно менять
3) объект может иметь поведение - методы
4) от класса объекта можно наследоваться
5) объектов одного класса может быть несколько
6) каждый объект уникален - находится в heap по своему адресу. Т.е. имеет identity
Можно ли отобрать у объекта что-то из вышеперечисленного в Java?
1) final class - запрещаем наследование
2) sealed class - если полный запрет нам не подходит, то ограничиваем наследование https://habr.com/ru/companies/otus/articles/720044/
3) final поля - запрещаем менять данные класса после создания объекта - иммутабельность
4) records - запрещаем методы и изменение полей https://habr.com/ru/articles/487308/ Основое применение - DTO, где есть только данные и их нежелательно менять.
5) lambda - можно рассматривать как объект-функцию без данных, хотя технически это не так - JVM под капотом транслирует ее в статический метод https://javadungeon.wordpress.com/2017/08/02/java-8-lambdas-under-the-hood/
6) object в Kotlin - синлетона на уровне языка в Java нет, но такую конструкцию сделали в Kotlin
7) value class - еще не реализованная в Java концепция, которая по сути добавляет в язык что-то среднее между примитивным типом и объектом. Т.е. у нас будет объект, но в плане занимаемой памяти он будет почти также эффективен, как и примитив. Что важно: т.к. это объект - его можно будет использовать в generics. Ура-ура!. Детали: https://www.baeldung.com/java-valhalla-project Но ничего не бывает бесплатно - у такого объекта не будет identity, т.е. два объекта с одинаковыми полями считаются одинаковыми. Также, как это сейчас происходит с примитивными типами. Да, для объектов это уже сейчас можно реализовать на уровне кода. А тут идея сделать тоже самое на уровне JVM. Т.е. JVM может (обязана?) оставить один экземпляр для всех одинаковых объектов. Причем так, как это сделано сейчас со строками - вариант не очень, т.к. остается "дыра" с конструктором, который по определению всегда создает новый объект. Т.е. для value class нельзя использовать публичный конструктор, нужен какой-то фабричный метод - как элемент языка. Примеры, когда это полезно: те же классы-обвертки для чисел или географические объекты.
#java #oop #kotlin
Хабр
Sealed классы Java в действии: создание надежных и безопасных приложений
Sealed (закрытые или запечатанные) классы были представлены в Java 15 в качестве способа ограничить иерархию наследования класса или интерфейса. Sealed класс...
Всем привет!
Минутка самообразования. В России есть две крупнейших конференции по Java разработке - JPoint и Joker. Они платные, с одним бесплатным днем, доступным после регистрации. Но главное - через какое-то время все доклады конференции, которые были записаны, становятся открытыми. Уже доступны доклады с JPoint 2023 - https://www.youtube.com/playlist?list=PLVe-2wcL84b9iHBMgj3Mjgr7Lg-FER8jP
Докладов целых 60 штук, тематика очень разнообразная, в отличие от прошлых лет. Я для себя нашел как минимум с десяток интересных.
Enjoy)
#conferences #jpoint
Минутка самообразования. В России есть две крупнейших конференции по Java разработке - JPoint и Joker. Они платные, с одним бесплатным днем, доступным после регистрации. Но главное - через какое-то время все доклады конференции, которые были записаны, становятся открытыми. Уже доступны доклады с JPoint 2023 - https://www.youtube.com/playlist?list=PLVe-2wcL84b9iHBMgj3Mjgr7Lg-FER8jP
Докладов целых 60 штук, тематика очень разнообразная, в отличие от прошлых лет. Я для себя нашел как минимум с десяток интересных.
Enjoy)
#conferences #jpoint
Всем привет!
К двум моим статьям про k8s (https://t.me/javaKotlinDevOps/6) и Istio (https://t.me/javaKotlinDevOps/210) прямо напрашивается третья - про Openshift.
Тут может возникнуть вопрос - а что это вообще такое и почему напрашивается?)
Ответ: это "допиленный напильником" k8s от компании Redhat для enterprise.
Поэтому если вы работаете в enterprise, особенно кровавом, то тема актуальная)
Второй вопрос, который может возникнуть - какой такой западный enterprise в России сейчас?
Ответ: есть opensource версия https://habr.com/ru/companies/redhatrussia/articles/511800/
Итак, что же добавляет Openshift к k8s.
1) Istio - включен в дистрибутив
2) встроенный Docker Registry
Небольшое уведомление. Основной пласт возможностей, которые предоставляет Openshift, реализован за счет кастомных ресурсов - CRD - и оператора, который их обрабатывает.
https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
https://habr.com/ru/companies/slurm/articles/556860/
Идем дальше.
3) настройки безопасности: ролевая модель https://docs.openshift.com/container-platform/4.8/rest_api/role_apis/role-apis-index.html, авторизация https://docs.openshift.com/container-platform/4.8/rest_api/authorization_apis/authorization-apis-index.html , OAuth https://docs.openshift.com/container-platform/4.8/rest_api/oauth_apis/oauth-apis-index.html
4) механизм шаблонов (ресурс типа Template) - позволяет в одном файле задать несколько ресурсов с параметрами. Значения параметров можно как задать в самом шаблоне (значения по умолчанию), так и передать в момент применения Template
https://docs.openshift.com/container-platform/4.8/rest_api/template_apis/template-apis-index.html
5) Имея механизм шаблонов, ролевую модель и настройку лимитов из k8s можно упростить создание новых namespace: для этого вводится проект - аналог namespace в Openshift. https://docs.openshift.com/container-platform/4.8/rest_api/project_apis/project-apis-index.html
6) самое интересное - концепция build-related ресурсов. Идея в том, что при изменении исходников или появлении нового образа в Docker происходит автоматическая сборка и установка новой версии приложения. Т.е. фактически мы получаем встроенный в кластер CI\CD.
https://docs.openshift.com/container-platform/4.10/cicd/index.html
https://docs.openshift.com/container-platform/4.8/rest_api/workloads_apis/buildconfig-build-openshift-io-v1.html
Данная концепция приводит к тому, что стандартный ресурс Deployment в Openshift заменяется на очень похожий DeploymentConfig, поддерживающий пересоздание подов при появлении нового кода https://docs.openshift.com/container-platform/4.8/rest_api/workloads_apis/deploymentconfig-apps-openshift-io-v1.html
7) само собой новая веб-консоль и новая CLI утилита (oc), поддерживающие все вышеописанные возможности.
Вот пожалуй и все основные отличия Openshift. В целом неплохо, хотя и не так революционно, как Istio
#openshift #istio #cloud #k8s
К двум моим статьям про k8s (https://t.me/javaKotlinDevOps/6) и Istio (https://t.me/javaKotlinDevOps/210) прямо напрашивается третья - про Openshift.
Тут может возникнуть вопрос - а что это вообще такое и почему напрашивается?)
Ответ: это "допиленный напильником" k8s от компании Redhat для enterprise.
Поэтому если вы работаете в enterprise, особенно кровавом, то тема актуальная)
Второй вопрос, который может возникнуть - какой такой западный enterprise в России сейчас?
Ответ: есть opensource версия https://habr.com/ru/companies/redhatrussia/articles/511800/
Итак, что же добавляет Openshift к k8s.
1) Istio - включен в дистрибутив
2) встроенный Docker Registry
Небольшое уведомление. Основной пласт возможностей, которые предоставляет Openshift, реализован за счет кастомных ресурсов - CRD - и оператора, который их обрабатывает.
https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
https://habr.com/ru/companies/slurm/articles/556860/
Идем дальше.
3) настройки безопасности: ролевая модель https://docs.openshift.com/container-platform/4.8/rest_api/role_apis/role-apis-index.html, авторизация https://docs.openshift.com/container-platform/4.8/rest_api/authorization_apis/authorization-apis-index.html , OAuth https://docs.openshift.com/container-platform/4.8/rest_api/oauth_apis/oauth-apis-index.html
4) механизм шаблонов (ресурс типа Template) - позволяет в одном файле задать несколько ресурсов с параметрами. Значения параметров можно как задать в самом шаблоне (значения по умолчанию), так и передать в момент применения Template
https://docs.openshift.com/container-platform/4.8/rest_api/template_apis/template-apis-index.html
5) Имея механизм шаблонов, ролевую модель и настройку лимитов из k8s можно упростить создание новых namespace: для этого вводится проект - аналог namespace в Openshift. https://docs.openshift.com/container-platform/4.8/rest_api/project_apis/project-apis-index.html
6) самое интересное - концепция build-related ресурсов. Идея в том, что при изменении исходников или появлении нового образа в Docker происходит автоматическая сборка и установка новой версии приложения. Т.е. фактически мы получаем встроенный в кластер CI\CD.
https://docs.openshift.com/container-platform/4.10/cicd/index.html
https://docs.openshift.com/container-platform/4.8/rest_api/workloads_apis/buildconfig-build-openshift-io-v1.html
Данная концепция приводит к тому, что стандартный ресурс Deployment в Openshift заменяется на очень похожий DeploymentConfig, поддерживающий пересоздание подов при появлении нового кода https://docs.openshift.com/container-platform/4.8/rest_api/workloads_apis/deploymentconfig-apps-openshift-io-v1.html
7) само собой новая веб-консоль и новая CLI утилита (oc), поддерживающие все вышеописанные возможности.
Вот пожалуй и все основные отличия Openshift. В целом неплохо, хотя и не так революционно, как Istio
#openshift #istio #cloud #k8s
Telegram
(java || kotlin) && devOps
Чем kubernetes, он же k8s лучше контейнера сервлетов или сервера приложений.
Во-первых под капотом k8s лежит Docker, а значит мы получаем все его плюшки. Не зря k8s называют оркестратором контейнеров. Чем занимается оркестратор?
1) планированиеи ресурсов.…
Во-первых под капотом k8s лежит Docker, а значит мы получаем все его плюшки. Не зря k8s называют оркестратором контейнеров. Чем занимается оркестратор?
1) планированиеи ресурсов.…
Всем привет!
Вопрос на собесе для джуна - что будет, если в Java число разделить на ноль?
А если это число с плавающей точкой?
Или все-таки это вопрос не для джуна, а со звездочкой... )))
Детали: https://www.baeldung.com/java-division-by-zero
А если говорить про задачи на собес - то можно вот такую: https://habr.com/ru/articles/573080/
P.S. Обратите внимание на автора блога.
P.P.S. На самом деле мне не очень нравятся задачи такого рода, т.к. такие вещи нужно просто знать. А главный вопрос - а нужно ли знать? Подозреваю, что 80% разработчиков с таким кейсом не столкнется в своей работе.
#java #trics
Вопрос на собесе для джуна - что будет, если в Java число разделить на ноль?
А если это число с плавающей точкой?
Или все-таки это вопрос не для джуна, а со звездочкой... )))
Детали: https://www.baeldung.com/java-division-by-zero
А если говорить про задачи на собес - то можно вот такую: https://habr.com/ru/articles/573080/
P.S. Обратите внимание на автора блога.
P.P.S. На самом деле мне не очень нравятся задачи такого рода, т.к. такие вещи нужно просто знать. А главный вопрос - а нужно ли знать? Подозреваю, что 80% разработчиков с таким кейсом не столкнется в своей работе.
#java #trics
Baeldung
Division by Zero in Java: Exception, Infinity, or Not a Number | Baeldung
When dividing by zero, integer division always throws an Exception. This is not the case with floating-point numbers, however. Let's see why.
Всем привет!
Формат yaml все больше входит в нашу жизнь, самые очевидные примеры - k8s, Docker Compose и Ansible.
Его главным преимуществом я считаю ссылки - соблюдается принцип DRY.
Главным недостатком - зависимость от числа tab\пробелов как в Python.
А чтобы не дать лишнему пробелу все сломать - нужна валидация.
Для начала - валидация синтаксиса https://yamllint.readthedocs.io/en/stable/index.html
Хотя в списке ОС для скачивания нет Windows - он ставится на Win с помощью python + pip.
Также есть плагин для IDEA https://plugins.jetbrains.com/plugin/15349-yamllint
Да, подсветка синтаксиса хотя и не заменяет валидацию, но тоже полезна - IDEA, Notepad++ и Atom поддерживают его из коробки.
Далее можно прикрутить валидацию, специфичную для конкретной области применения.
Для k8s есть утилиты kubeval, kube-score и Polaris см. https://habr.com/ru/companies/flant/articles/511018/
Они проверяют манифесты на соответствие best practices.
В docker-compose валидация вызывается с помощью команды https://docs.docker.com/engine/reference/commandline/compose_config/
Для Ansible - базовые проверки встроены в Ansible, также есть ansible-lint, детали см. https://www.deploymastery.com/2023/03/31/how-to-verify-ansible-playbook-syntax/
Альтернатива - написать нужные проверки самому. Тут есть 4 библиотеки из уже приведенной выше статьи:
config-lint, copper, conftest, Polaris
https://habr.com/ru/companies/flant/articles/511018/ Основное различие - в языке, на котором будет ваш код проверки. Есть и декларативный yaml, есть и императивный JS.
#yaml #k8s #ansible #docker-compose #validation
Формат yaml все больше входит в нашу жизнь, самые очевидные примеры - k8s, Docker Compose и Ansible.
Его главным преимуществом я считаю ссылки - соблюдается принцип DRY.
Главным недостатком - зависимость от числа tab\пробелов как в Python.
А чтобы не дать лишнему пробелу все сломать - нужна валидация.
Для начала - валидация синтаксиса https://yamllint.readthedocs.io/en/stable/index.html
Хотя в списке ОС для скачивания нет Windows - он ставится на Win с помощью python + pip.
Также есть плагин для IDEA https://plugins.jetbrains.com/plugin/15349-yamllint
Да, подсветка синтаксиса хотя и не заменяет валидацию, но тоже полезна - IDEA, Notepad++ и Atom поддерживают его из коробки.
Далее можно прикрутить валидацию, специфичную для конкретной области применения.
Для k8s есть утилиты kubeval, kube-score и Polaris см. https://habr.com/ru/companies/flant/articles/511018/
Они проверяют манифесты на соответствие best practices.
В docker-compose валидация вызывается с помощью команды https://docs.docker.com/engine/reference/commandline/compose_config/
Для Ansible - базовые проверки встроены в Ansible, также есть ansible-lint, детали см. https://www.deploymastery.com/2023/03/31/how-to-verify-ansible-playbook-syntax/
Альтернатива - написать нужные проверки самому. Тут есть 4 библиотеки из уже приведенной выше статьи:
config-lint, copper, conftest, Polaris
https://habr.com/ru/companies/flant/articles/511018/ Основное различие - в языке, на котором будет ваш код проверки. Есть и декларативный yaml, есть и императивный JS.
#yaml #k8s #ansible #docker-compose #validation
JetBrains Marketplace
Yamllint - IntelliJ IDEs Plugin | Marketplace
Provides static code analysis of Yaml files through integration with Yamllint. Enable and configure it in the Preferences > Tools > Yamllint.
Всем привет!
С большой вероятностью не ошибусь, если скажу, что большинство разработчиков не любит работать с legacy. Вижу это в резюме, сталкиваюсь с этим периодически на собеседованиях.
Почему? Там много кода, код непонятный, разбираться долго, нет новых технологий, есть куча правил, которые так просто не нарушишь...
А есть ли плюсы в работе с legacy?
Я как человек, примерно половину своей карьеры плотно работавший с legacy, могу сказать - да, есть.
Плюсы такие:
1) если речь идет не про поддержку, а про глубокий рефакторинг, то распилить legacy на микросервисы - это сложная архитектурная задача. Решив ее, получаешь опыт проектирования возможно даже больший, чем при создании этих сервисов с нуля. И этот опыт можно хорошо продать
2) не все legacy = го...код. Возможно все начиналось с хорошо спроектированного небольшого приложения, которое вовремя не разделили на части. Либо не хватало времени, либо не было необходимости. В таком случае в legacy приложении, особенно если оно достаточно большое, можно подсмотреть доказавшие свою полезность паттерны и архитектурные решения. А именно умение проектировать и наработанные паттерны являются основным преимуществом разработчика. Технологии меняются и их всегда можно доучить.
3) я достаточно много писал и буду писать о том, как важна читаемость кода, его компактность и в конечном итоге снижение когнитивной нагрузки при работе с кодом. Казалось бы это не про типичный legacy. В целом да. Но если все же научится "переваривать" большие объемы кода - это будет еще одним плюсом в копилку полезных навыков разработчика. Т.к. есть теория про "чистый код", а, увы, есть суровая практика. И "бизнес" любит людей, которые могут решить любую проблему, в т.ч. и с legacy.
4) любой сервис становится legacy. Поэтому отказываясь работать с legacy - сужаешь список своих возможностей. На растущем рынке это не критично, но всегда ли он будет так расти?
#legacy #skills
С большой вероятностью не ошибусь, если скажу, что большинство разработчиков не любит работать с legacy. Вижу это в резюме, сталкиваюсь с этим периодически на собеседованиях.
Почему? Там много кода, код непонятный, разбираться долго, нет новых технологий, есть куча правил, которые так просто не нарушишь...
А есть ли плюсы в работе с legacy?
Я как человек, примерно половину своей карьеры плотно работавший с legacy, могу сказать - да, есть.
Плюсы такие:
1) если речь идет не про поддержку, а про глубокий рефакторинг, то распилить legacy на микросервисы - это сложная архитектурная задача. Решив ее, получаешь опыт проектирования возможно даже больший, чем при создании этих сервисов с нуля. И этот опыт можно хорошо продать
2) не все legacy = го...код. Возможно все начиналось с хорошо спроектированного небольшого приложения, которое вовремя не разделили на части. Либо не хватало времени, либо не было необходимости. В таком случае в legacy приложении, особенно если оно достаточно большое, можно подсмотреть доказавшие свою полезность паттерны и архитектурные решения. А именно умение проектировать и наработанные паттерны являются основным преимуществом разработчика. Технологии меняются и их всегда можно доучить.
3) я достаточно много писал и буду писать о том, как важна читаемость кода, его компактность и в конечном итоге снижение когнитивной нагрузки при работе с кодом. Казалось бы это не про типичный legacy. В целом да. Но если все же научится "переваривать" большие объемы кода - это будет еще одним плюсом в копилку полезных навыков разработчика. Т.к. есть теория про "чистый код", а, увы, есть суровая практика. И "бизнес" любит людей, которые могут решить любую проблему, в т.ч. и с legacy.
4) любой сервис становится legacy. Поэтому отказываясь работать с legacy - сужаешь список своих возможностей. На растущем рынке это не критично, но всегда ли он будет так расти?
#legacy #skills
Всем привет!
Пару слов про отладку тестов, на примере Maven проекта и IDEA.
Если речь про модульные тесты - там проблем нет, ставим breakpoint и запускаем нужный тест в IDEA.
Проблемы есть с интеграционными тестами. Т.к.
1) тесты и код, который тестируем, запускаются в разных процессах
2) обычно интеграционные тесты запускаются с помощью Maven (Gradle), т.к. нужно поднять окружение, и проще и правильнее эти настройки один раз сделать в Maven и забыть.
Какие у нас варианты с отладкой?
1) вариант, описанный тут https://stackoverflow.com/questions/49390110/how-to-debug-integration-test-in-intellij
Если вкратце - запускаем тесты с помощью Maven в специальном отладочном режиме плагина failsafe (или surefire), потом подключаемся к процессу из IDEA в режиме удаленной отладки. Отладка называется удаленной, т.к. нужно подключаться к другому процессу. В данном случае на localhost.
2) запускаем наш сервис в "DEV режиме" через Maven. Также, как это делается для отладки кода и проверки функционала локально вручную. Обычно под это дело в проекте есть отдельный профиль Maven. После этого запускаем нужный интеграционный тест в Debug режиме из IDEA, из окна с кодом теста. Как минимум, интеграционные тесты Cucumber и Spring Boot IDEA поддерживает.
3) а что, если нужно поставить точку прерывания в коде сервиса, а не тестов? Тогда настаиваем в IDEA Run configuration для нашего контейнера сервлетов \ сервера приложений. Запускаем ее в DEBUG режиме, после чего запускаем тесты также, как и в предыдущем варианте.
Варианты 2 и 3 мне нравятся больше, т.к. не нужно использовать консоль - все делается средствами IDEA.
#debug #java #tests #integration-tests
Пару слов про отладку тестов, на примере Maven проекта и IDEA.
Если речь про модульные тесты - там проблем нет, ставим breakpoint и запускаем нужный тест в IDEA.
Проблемы есть с интеграционными тестами. Т.к.
1) тесты и код, который тестируем, запускаются в разных процессах
2) обычно интеграционные тесты запускаются с помощью Maven (Gradle), т.к. нужно поднять окружение, и проще и правильнее эти настройки один раз сделать в Maven и забыть.
Какие у нас варианты с отладкой?
1) вариант, описанный тут https://stackoverflow.com/questions/49390110/how-to-debug-integration-test-in-intellij
Если вкратце - запускаем тесты с помощью Maven в специальном отладочном режиме плагина failsafe (или surefire), потом подключаемся к процессу из IDEA в режиме удаленной отладки. Отладка называется удаленной, т.к. нужно подключаться к другому процессу. В данном случае на localhost.
2) запускаем наш сервис в "DEV режиме" через Maven. Также, как это делается для отладки кода и проверки функционала локально вручную. Обычно под это дело в проекте есть отдельный профиль Maven. После этого запускаем нужный интеграционный тест в Debug режиме из IDEA, из окна с кодом теста. Как минимум, интеграционные тесты Cucumber и Spring Boot IDEA поддерживает.
3) а что, если нужно поставить точку прерывания в коде сервиса, а не тестов? Тогда настаиваем в IDEA Run configuration для нашего контейнера сервлетов \ сервера приложений. Запускаем ее в DEBUG режиме, после чего запускаем тесты также, как и в предыдущем варианте.
Варианты 2 и 3 мне нравятся больше, т.к. не нужно использовать консоль - все делается средствами IDEA.
#debug #java #tests #integration-tests
Stack Overflow
How to debug integration test in IntelliJ?
I have created run configuration in Maven Projects for
mvn -Dit.test=PredictionWorkflowTest verify
which looks like here
and then set breakpoint inside PredictionWorkflowTest. Unfortunately, whe...
mvn -Dit.test=PredictionWorkflowTest verify
which looks like here
and then set breakpoint inside PredictionWorkflowTest. Unfortunately, whe...