форматеры может быть не такие уж и плохие, например, мне кажется достаточно продвинутой возможность в IntelliJ IDEA настроить параметры форматирования визуально редактируя образцы кода. А результат в обзоре получается не очень, скорее, потому что рассматриваемый тестовый образец достаточно сложен. По собственному опыту могу сказать, что лажают и форматеры для других языков, много раз я боролся с eslint для тайпскрипта глуша его специальными комметариями(что тоже не всегда возможно и часто создает необходимость переписывать код на менее элегантный). Форматирование даже такого "детерменированного" формата как html в интелидже может делать переносы совершенно не там, где это было бы логично, т.е. может перенести на новую строку один закрывающий тег. Есть еще такое наблюдение, что форматтилками увлекаются в большей степени там, где "стандартное" форматирование достаточно необычно, например в go где, кемел.КейсНаоборот будет выглядеть странно для пришедшего с пхп, безальтернативная форматилка входит в тулчейн компилятора/интерпретатора.
да, недавно на JUG.ru был разбор со всеми кишочками и планом: https://www.youtube.com/watch?v=TUshoGb9BDk однако, вероятно, не все разработчики продуктов сразу смогут заменить нынешний ASM
главное вроде - ClassFile API, который дает надежду, что все груви, спринги, ломбки и прочие технологии активно использующие метапрограммирование перестанут ломаться с каждым новым релизом
спасибо, думаю, производительность при высоких нагрузках это задача инфраструктурного уровня. Про горизонтальное масштабирование jmix есть раздел в документации по которому не трудно настроить хоть кубер хоть сворм, хоть клауд-хостинг
практически все рассказывающие о виртуальных потоках отмечают, что их не рекомендуется применять для кода с большой интенсивностью и количеством syncronized блоков (не знаю понятно ли это из объяснения в статье, но если коротко: блокирующая операция в синхронизированном блоке "приклеивает"(литературный перевод pin), т.е. блокирует платформенный поток) и вообще они предполагаются не для задач использующих общие ресурсы и не для замены платформенных потоков, а тут кажется они "наоборот" пытаются сделать из томкета nodejs
общее то, что они работают по принципу авианосца, когда есть пул реальных потоков, на которые распределяется выполнение виртуальных. А эвентлуп у вас будет и в приложении, что управляет задачами виртуальных потоков или вы его сымитируете. Нет, ну можно конечно и подождать джойном или что-то такое ещё использовать, но это получится эвентлуп с одной итерацией;)
Ну реакт то еще дальше от будущего. Даже чисто хронологически веб-компоненты, на которых основана фронтенд-часть ваадина содержат заимствования из него в виде хуков типа componentDidMount. К сожалению, кроме хорошего они еще затащили там и такие вещи как харкод верстки в JavaScript вместо использования шаблонов. И для бекендера, фронтендера других фреймворков и специализаций вся эта стилистика кодирования часто действительно представляет собой другой дивный и чудный мир. Гораздо более нестабильный чем API спринговых дополнений. Кто сейчас помнит и чтит БЭМ, tailwind, handlebars/pug, modernizr, core-js с полифилами, reflux/mobx? А с ваадином они могут разрабатывать в привычных терминах со слоями, полиморфизмом и другими общепринятыми и неискаженными в разработке принципами и делать это на прикладных задачах с предсказуемой производительностью. А в Jmix у них будут еще дизайнеры форм и бизнес-процессов с генераторами кода, миграций и дополнения в конце-концов функционал которых не придется колхозить самим роняя тапки на почасовке.
Думаю, тут несколько проще будет прикинуть требования, чем для микросервисной архитектуры например. Но для корпоративных приложений и такой вариант с фиксированным потолком одновременных пользователей мог бы подойти. Хотя я сейчас не вижу особых препятствий для горизонтального масштабирования.
Многие программисты не любят заниматься фронтендом и, вообще, мало какие могут его делать на высоком качественном уровне, а тут для них это все убрали под капот, при том оставив возможности туда лазить. Кроме того, на эффективности и качестве очень сказывается то, что в разработке части одной подсистемы делает от 2-х специалистов (фронт и бек), которым приходится координировать работу и еще и синхронизироваться с менеджментом и тестировщиками. Мое видение такое, что если есть достаточно компетенций и бюджета что-бы выстроить архитектуру и технологику лучше чем в приложении с Vaadin, безусловно лучше это сделать, но такое смогут не более пары % от совокупного рынка веб-разработки. Остальные просто будут менять одну популярную технологию на другую второпях переписывая все заново каждый раз.
Виртуальные треды сделали как раз что-бы не троттлить вычисления, т.е. не блокировать платформенные(реальные) потоки лишний раз. Судя по бенчмаркам они никак не ухудшают и не улучшают чистой производительности вычислений, это конечно без учета затрат на создание новых платформенных потоков и как раз этих самых простоев на блокировках. Важный момент тут в том, что виртуальные потоки выполняются на пуле реальных потоков, т.е. они не вместо платформенных, а вместе. Мне кажется, "реактивный стек", такой как в Vert.x - это как раз то, что стало основой для виртуальных потоков, не уверен, что он будет работать производительнее виртуальных. Ну а задача рисования точек на карте гораздо менее требовательна чем рисование пользователями на холсте, и там ботлнек будет в частоте поступления данных от GPS.
между требованиями иметь как можно меньше внешних зависимостей и выполнять только одну задачу и при том хорошо в реальной жизни восновном будет возникать противоречие, т.к. если вы, например, имеете потребность, но не используете XStream или его аналог как зависимость, значит вы решаете его задачу внутри своей разработки т.е. добавляете ее к перечню задач решаемых вашей единицей кода. Решение проблемы с логгерами лежало где-то как раз в сфере SOLID: 1) зависеть от интерфейсов, а не от реализаций, 2) не иметь дублирующих реализаций в рамках одной системы.
Причём локально только для того, чтобы посмотреть, как запустился и отработал пайплайн — то есть фактически протестировать сам .gitlab-ci.yaml. Я здесь прав или ошибаюсь?
В том числе протестировать пайплайн, ситуация может быть различной, у вас могут быть отдельные виртуалки или железяки под все включая реестр, надо быть готовым ко всему. Специфика данной статьи - джава-проекты которые надо деплоить автоматически, докер как среда их выполнения, гитлаб как система неприрывной интеграции. Вы не становитесь сисадмином от того, что выполнеяте docker start локально или на выделенном сервере.
Да. Но мне ещё здесь хочется добавить, что удобнее общаться в стиле декларативных зависимостей, а не инструкций.
просто не всегда бывает так, что вы можете все определить самостоятельно и решить задачу "с нуля", реестр может потребоваться использовать уже готовый и сторонний, например из артифактори или нексуса или того же докерхаба или аналога. Конкретно для программиста отдельный реестр удобнее в том плане, что гитлаб наигравшись можно выключить, а реестр оставить для поддержки других своих задач.
девопс это почти сисадмин готовый заниматься вопросами выше уровней сетевой маршрутизации, но он не программист и может и не знать для чего надо запускать препроцессоры или с какими профилями собирать. Конечно, надо ему эти знания как-то передать, но прежде чем это получится сделать этот процесс желательно проработать разработчику, т.к. если с какой-то проблемой застрянет девопс ему разобраться в особенностях наделанного программистами будет гораздо сложнее. Ну и я совершенно не возражаю против того, что бы этой статьей воспользовались сисадмины и девопсы, даже хочу им помочь как в плане получения базовых рецептов, так и специфики типа развертывания джава-приложений в контейнерах.
Если вы отлаживаете их на локальном инстансе, вы гарантируете, что настройки раннеров и всех других важных административных настроек идентичны тем, что на удаленной среде?
хорошим тоном в таких процессах являются "чистые" сборки, не зависимые даже от историчности запусков не говоря уже о особенностях внешней среды, а одинаковость настроек не требуется, т.к. они определяются внешними по отношению к артефакту/контейнеру параметрами. Но вообще, обычно, тестовая среда максимально вариативна для лучшего выявления проблем, а стейдж - максимально приближен к продуктиву, иногда делается прямо на основе него.
Смотря, что вы имеете ввиду под этими словами. Сборка — скрипт, запускаемый в джобе?
некий набор операций которые необходимы для преобразования исходников в артефакты для запуска на тестовых или продуктивных серверах: получение, сборка, упаковка, прогон тестов. Все они могут принадлежать разным источникам и иметь разную природу. Кроме того, это может быть какая-то новая для вашей ситуации технология или контекст. Девопсам или сисадминам, как минимум, могут потребоваться конкретные инструкции по настройке сложного процесса полностью понимать который будет только разработчик.
форматеры может быть не такие уж и плохие, например, мне кажется достаточно продвинутой возможность в IntelliJ IDEA настроить параметры форматирования визуально редактируя образцы кода. А результат в обзоре получается не очень, скорее, потому что рассматриваемый тестовый образец достаточно сложен. По собственному опыту могу сказать, что лажают и форматеры для других языков, много раз я боролся с eslint для тайпскрипта глуша его специальными комметариями(что тоже не всегда возможно и часто создает необходимость переписывать код на менее элегантный). Форматирование даже такого "детерменированного" формата как html в интелидже может делать переносы совершенно не там, где это было бы логично, т.е. может перенести на новую строку один закрывающий тег. Есть еще такое наблюдение, что форматтилками увлекаются в большей степени там, где "стандартное" форматирование достаточно необычно, например в go где, кемел.КейсНаоборот будет выглядеть странно для пришедшего с пхп, безальтернативная форматилка входит в тулчейн компилятора/интерпретатора.
да, недавно на JUG.ru был разбор со всеми кишочками и планом:
https://www.youtube.com/watch?v=TUshoGb9BDk
однако, вероятно, не все разработчики продуктов сразу смогут заменить нынешний ASM
главное вроде - ClassFile API, который дает надежду, что все груви, спринги, ломбки и прочие технологии активно использующие метапрограммирование перестанут ломаться с каждым новым релизом
нагуглил статейку в которой рассказывается как обнаруживать запинивающиеся потоки:
https://todd.ginsberg.com/post/java/virtual-thread-pinning/
спасибо, думаю, производительность при высоких нагрузках это задача инфраструктурного уровня. Про горизонтальное масштабирование jmix есть раздел в документации по которому не трудно настроить хоть кубер хоть сворм, хоть клауд-хостинг
https://docs.jmix.ru/jmix/deployment/k8s.html
VS Code на большом проекте может выжрать и больше, когда я специально сравнивал, было на пару гигов разницы
практически все рассказывающие о виртуальных потоках отмечают, что их не рекомендуется применять для кода с большой интенсивностью и количеством syncronized блоков (не знаю понятно ли это из объяснения в статье, но если коротко: блокирующая операция в синхронизированном блоке "приклеивает"(литературный перевод pin), т.е. блокирует платформенный поток) и вообще они предполагаются не для задач использующих общие ресурсы и не для замены платформенных потоков, а тут кажется они "наоборот" пытаются сделать из томкета nodejs
ситуация похожа на накопление фильмов на диске%)
общее то, что они работают по принципу авианосца, когда есть пул реальных потоков, на которые распределяется выполнение виртуальных. А эвентлуп у вас будет и в приложении, что управляет задачами виртуальных потоков или вы его сымитируете. Нет, ну можно конечно и подождать джойном или что-то такое ещё использовать, но это получится эвентлуп с одной итерацией;)
Ну реакт то еще дальше от будущего. Даже чисто хронологически веб-компоненты, на которых основана фронтенд-часть ваадина содержат заимствования из него в виде хуков типа componentDidMount. К сожалению, кроме хорошего они еще затащили там и такие вещи как харкод верстки в JavaScript вместо использования шаблонов. И для бекендера, фронтендера других фреймворков и специализаций вся эта стилистика кодирования часто действительно представляет собой другой дивный и чудный мир. Гораздо более нестабильный чем API спринговых дополнений. Кто сейчас помнит и чтит БЭМ, tailwind, handlebars/pug, modernizr, core-js с полифилами, reflux/mobx? А с ваадином они могут разрабатывать в привычных терминах со слоями, полиморфизмом и другими общепринятыми и неискаженными в разработке принципами и делать это на прикладных задачах с предсказуемой производительностью. А в Jmix у них будут еще дизайнеры форм и бизнес-процессов с генераторами кода, миграций и дополнения в конце-концов функционал которых не придется колхозить самим роняя тапки на почасовке.
Думаю, тут несколько проще будет прикинуть требования, чем для микросервисной архитектуры например. Но для корпоративных приложений и такой вариант с фиксированным потолком одновременных пользователей мог бы подойти. Хотя я сейчас не вижу особых препятствий для горизонтального масштабирования.
Многие программисты не любят заниматься фронтендом и, вообще, мало какие могут его делать на высоком качественном уровне, а тут для них это все убрали под капот, при том оставив возможности туда лазить. Кроме того, на эффективности и качестве очень сказывается то, что в разработке части одной подсистемы делает от 2-х специалистов (фронт и бек), которым приходится координировать работу и еще и синхронизироваться с менеджментом и тестировщиками.
Мое видение такое, что если есть достаточно компетенций и бюджета что-бы выстроить архитектуру и технологику лучше чем в приложении с Vaadin, безусловно лучше это сделать, но такое смогут не более пары % от совокупного рынка веб-разработки. Остальные просто будут менять одну популярную технологию на другую второпях переписывая все заново каждый раз.
Виртуальные треды сделали как раз что-бы не троттлить вычисления, т.е. не блокировать платформенные(реальные) потоки лишний раз. Судя по бенчмаркам они никак не ухудшают и не улучшают чистой производительности вычислений, это конечно без учета затрат на создание новых платформенных потоков и как раз этих самых простоев на блокировках. Важный момент тут в том, что виртуальные потоки выполняются на пуле реальных потоков, т.е. они не вместо платформенных, а вместе.
Мне кажется, "реактивный стек", такой как в Vert.x - это как раз то, что стало основой для виртуальных потоков, не уверен, что он будет работать производительнее виртуальных.
Ну а задача рисования точек на карте гораздо менее требовательна чем рисование пользователями на холсте, и там ботлнек будет в частоте поступления данных от GPS.
картинки ставят для привлечения внимания;)
между требованиями иметь как можно меньше внешних зависимостей и выполнять только одну задачу и при том хорошо в реальной жизни восновном будет возникать противоречие, т.к. если вы, например, имеете потребность, но не используете XStream или его аналог как зависимость, значит вы решаете его задачу внутри своей разработки т.е. добавляете ее к перечню задач решаемых вашей единицей кода. Решение проблемы с логгерами лежало где-то как раз в сфере SOLID: 1) зависеть от интерфейсов, а не от реализаций, 2) не иметь дублирующих реализаций в рамках одной системы.
В том числе протестировать пайплайн, ситуация может быть различной, у вас могут быть отдельные виртуалки или железяки под все включая реестр, надо быть готовым ко всему. Специфика данной статьи - джава-проекты которые надо деплоить автоматически, докер как среда их выполнения, гитлаб как система неприрывной интеграции. Вы не становитесь сисадмином от того, что выполнеяте docker start локально или на выделенном сервере.
просто не всегда бывает так, что вы можете все определить самостоятельно и решить задачу "с нуля", реестр может потребоваться использовать уже готовый и сторонний, например из артифактори или нексуса или того же докерхаба или аналога. Конкретно для программиста отдельный реестр удобнее в том плане, что гитлаб наигравшись можно выключить, а реестр оставить для поддержки других своих задач.
девопс это почти сисадмин готовый заниматься вопросами выше уровней сетевой маршрутизации, но он не программист и может и не знать для чего надо запускать препроцессоры или с какими профилями собирать. Конечно, надо ему эти знания как-то передать, но прежде чем это получится сделать этот процесс желательно проработать разработчику, т.к. если с какой-то проблемой застрянет девопс ему разобраться в особенностях наделанного программистами будет гораздо сложнее. Ну и я совершенно не возражаю против того, что бы этой статьей воспользовались сисадмины и девопсы, даже хочу им помочь как в плане получения базовых рецептов, так и специфики типа развертывания джава-приложений в контейнерах.
хорошим тоном в таких процессах являются "чистые" сборки, не зависимые даже от историчности запусков не говоря уже о особенностях внешней среды, а одинаковость настроек не требуется, т.к. они определяются внешними по отношению к артефакту/контейнеру параметрами. Но вообще, обычно, тестовая среда максимально вариативна для лучшего выявления проблем, а стейдж - максимально приближен к продуктиву, иногда делается прямо на основе него.
некий набор операций которые необходимы для преобразования исходников в артефакты для запуска на тестовых или продуктивных серверах: получение, сборка, упаковка, прогон тестов. Все они могут принадлежать разным источникам и иметь разную природу. Кроме того, это может быть какая-то новая для вашей ситуации технология или контекст. Девопсам или сисадминам, как минимум, могут потребоваться конкретные инструкции по настройке сложного процесса полностью понимать который будет только разработчик.
А что делать если вам надо отладить саму сборку или пайплайн и сисадмины такого точно не смогут?