Переписывать код бизнес-логики в 2025 году стоит смешных денег. Вы не кодеки для видео пишете и не ЛЛМки растите. У вас есть строго кодифицированные процедуры, которые на другой язык можно переложить с закрытыми глазами.
Автор этого длинного и многословного текста похоже никогда не сталкивался с задачами переписывания действительно старого объемного ПО, на которое толком спецификаций нет и пр. И не простого и понятного кусочка/модуля, а чего то более менее сложного и комплексного.
Я сталкивался. Сводить все к синктаксису языков программирования и использования LLM вызывает у меня нервное хихикание. И явно отражает только теоретический "опыт" автора в этом вопросе. В общем: "Что нам строит дом посторить: нарисуем - будем жить".
Когда 90% времени (в лучшем случае) тратишь не на само переписывание как таковое, с одного языка на другой, а на разборки "а зачем это и что это делает в конечном итоге". Не с точки зрения байтиков битиков, а высокоуровнево. Даже, когда в целом понимаешь зачем и для чего, разбор занимает массу времени. Особенно на "боковые" ветки логики, на которые в жизни внятных логов нет и никто не может сказать используется это и при каких условиях возникает.
Особенно весело, когда наступает фаза тестирования (нет ни тест кейзов ни общего знания как все целиком работает что бы их составить). И когда переписанное ПО приносит неожиданные сюрпризы в "боковых" ветках логики (про которые никто не помнит и которые возникают неожиданно на бою). А еще веселее, когда это ПО связано с финансами и любая ошибка в продакшн - это ооочень больно.
А "не протестированное ПО - это 100% не рабочее ПО". И даже прототестированное ПО - это на 50% рабочее ПО (с вероятностю 1/2. Либо встретишь в нем ошибку или не встретишь на этапе эксплуатации).
Кстати, это беда очень многих статей на хабре. Все сводится к кодированию. Я уже оочень давно занимаюсь разработкой ПО. Так вот кодирование - это совсем небольшая часть работы в разработке ПО. И по большому счету пофиг на чем (язык, фреймворк). Основное - это понять что нужно (и понять/договорится что это именно то хочется получить). Я вообще часто удивляюсь как люди друг друга еще понимают. У свой образ "реального мира в голове", а слова языка дают иллюзию, что этот образ "как бы один".
Все что запомнил. Марина была небольшая. Посмотрел сейча по спутниковым снимкам. Не опознаю какая, но 100% не Алимос . Я же писал, что ездил "баластом" и все организационные вещи не вникал. Как мне объяснили, яхта частная и сдавалась через агентсво (напрямую никто не сдает). Как ее нашли, через какое агенство - мне было тогда не интересно. Поездка вообще была бюджетной. Я очень удивился, что в сумме ночевка 3 суток в гостинице стоила почти как 7 дней моего вклада в аренду. Именно в аренду. Что там на топливо скидывались и на продукты на месте уже по факту. Да. Такая яхта для прогулок. От острова к острову с ночевками либо в маринах либо разово в какой ни будь бухте.
Под прогулочной яхтой/катамароном я имел виду формат (в Тае) аренды на 10-15 чел в формате "от пляжа к пляжу вдоль берега". Чаще всего (в Тае) в ареду на неделю сдают с шкипетром, если в компании своего не будет. И в сумме, аренда на человека и еда - это приблизительно столько же, если то же время время на берегу (гостиницы 2* + поездки = 1000-1500$ в 2 недели у меня уходит в Тае). В сумме на яхте даже дешевле. Доп траты только на еду. Мне такой отдых не зашел. Скучно. Компанию с дайверами под такой формат не нашел (может и нет таких арендных яхт с копрессором и местом под баллоны).
Так что, "прогулочный" не в смылсе длинны переходов, а в смысле "место переночевать, переместится на 20..50 км в строну и снова переночевать".
Яхты "для мыса горн" упомянул под впечатления ролика на ютюбе где показывалось путешествие как раз через мыс горн. Жуткие виды огромных волн, вахты с коротким сном в сырости и все это за нехилые деньги.
У нас разный опыт. Вы судите, исходя исключительно из своего опыта, и не допускате что существет что то другое типа бюджетной аренды мелкой (и довольно убитой жизнью) яхты на 3 каюты на 6-7 человек или катамарана в Тае для "пляжно/яхтного отдыха".
Я вообще не пытаюсь затрагивать в рассужения ту строну, которую не знаю. И говорил про свой личный (пусть и весьма ограниченный) опыт. И не более. Но все же личный опыт, а не со слов.
В марине, из которой в Афинах выходили, все яхты были до 30 футов. Почти все можно было взять в аренду на компании 6-7 человек. Все разномастные. Все частные.
Все это для аренды обычно под компании со своим шкипром любителем и такой же компании фанатиков яхт спорт. Полно тематических форумов на которых народ собирается и организовывает в складчину такие выезды погонять на регатах и пр. Попасть туда матросом - сложно. Баластом (пай в) - обычно без проблем. Но именно баластом :) Порулить и веревки подергать - очередь :) По крайней мере было до 2022.
Вы говорите о другом классе аренды. Прогулочные катамараны.. красотки с бокалами шампанского на сандеке (утрирую). Как правило шкипер в комплекте, а иногда и команда минимальная в комплекте к аренде (не обязательно). Есть конечно и аренда больших яхт океанского класса (типа обойти мыс Горн). Но там запредельные цены и я с этим живьем не сталкивался.
Так что, если Вы с чем то не сталкивались, то не значит, что этого не существует.
Довольно лукавые расчеты. А никто не задумывается откуда такие цены... Попал как то яхту в качетве "баласта" (Греция). Остальной народ учился что бы получать международные корочки шкипера. А я так.. просто за компанию.
Вопросы к "преподавателю" "студентов" были как раз такого плана: "я же могу взять.. это же не дорого". Он как раз и говорил в ответ: "купите. вложитесь.. поиграетесь пару отпусков, посчитаете сумму в год и будете продавать демпингуя - вот от этого такие цены".
Умалчивается, сколько стоит обслуживать (хотя бы просто выдернуть из воды краном). Можно, конечно, просто купить, вложится в состояние "авось не утонет" и бросать в воде на год. Года на 2 хватит особено в южных морях. А потом на помойку. Все же это не автомобиль. А жить на яхте долго - это не для всех.
Все арендные яхты (ну в Греции точно) это чьи то. И сдают их в аренду, что бы по минимум отбить траты на содержание.
Конечно все это со слов шкипера, которого учил группу. Он не отговаривал. Просто объяснял расклады и подводные камни такого варианта как своя яхта.
Да. Слышал и такой вариант. Только на Axiom JDK особой разницы не заметно на тестах.
А еще можно вынести файлы *.class из jar архива. А еще можно *.class положить в FS созданный в RAM и.. иного еще я слышал путей (на коференциях и в кулуарах) как ускорить старт SpringBoot приложения.Включая даже такую экзотику, как собственный форк SpringBoot для того что бы делать "прогрев". (не помню что подразумевали авторы. давно было)
А можно просто не использовать SpringBoot для высоконагруженных сервисов Java которым требуется быстрый старт.
Есть опыт переписывания HTTP сервисов со Spring на "просто страрт из main http сервера с REST API+пул jdbc коннектов". не так уж много дополнительно кода требуется, что бы явно указывать зависмости, пользоваться @Ingect "из коробки" и самому обрабатывать анотации там где это нужно, а не по всем классам прикладного кода. Ничего сложного в этом нет. после такой переделки, ресурсы, потребляемые сервисом для старта сокращаются кардинально. Есть с чем сравнивать. И это важно для прома, когда из железа нужно выжать максимум.
Почему то все просто помешались на этом SpringBoot. Как будто ничего другого нет.
SpringBoot, в сущьности, довольно простой, если брать основу (автоматические связи между компонентами прикладного кода). А все остальное в нем, это зачастую кривонаписанные обертки поверх других продуктов/либ (Hibernate, Http сервера, kafka и пр.).
А насчет Jooq... Когда тратишь кучу времни, что бы найти как добавить в SQL, который порождает Hibernate, специфичный вариант синтаксиса (а hibernate типа как бы "сам лучше знает чем я"), то собрать грабли на другой дорожке уже не хочется.
Spring обертывет своим кодом и kafka и Tomcat под свои особенности. Но вообще никто не мешает использовать kafka даже внутри Springboot напрямую. Особенно, когда хочется использовать какую ни будь фичу либы клиента kafka, а разработчики SpringBoot не захотели (посчитали не нужным) вынести ее в API Spring.
.. final KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props); .. while (!Thread.interrupted()) { .. ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(dt));
То же самое и с реализацией API web, которая есть у всех Http серверов (tomcat, grizzly, jetty,..) Дело вкуса, но стандарт анотаций javax.ws.rs.* @POSTT, @Path, @Consumes,..) мне больше нравится чем "стандарт" анотаций Spring @RequestMappingg). Хотя это субъективно и не имеет никакого принципиального значения.
Кстати, во всех Http серверах "из коробки" есть поддержка @Inject в реализации классов API. Конечно, не автоматом сборка бинов, а нужно руками при старте сервера указать какие классы хочешт инжекнуть и как.
В общем, список того что мне не нравится в SpringBoot (в порядке приоритета)
Автоматический сбор зависимостей это удобство для программиста, но большая нагрузка и ресурсы сервера на старте программы.
Оболочки Spring вокруг стандартных либ подходят для 99% задач, но когда возникает что то не стандартное, то либо нужно пробиваться к нужным вызовам через рефлексию, по пути долго матерясь и копаясь в исходниках Spring или использовать вызовы либ напрямую. В общем, шаг в строну - уже проблема.
Красота и удобство кода не = производительности. Местами приходилось красивый "функциональный" вызов stream заменять на не красиывый for ради экономии долей ms.
Да. Сейчас набежит куча советчиков типа "советую посмотреть в сторону Spring Data Jdbc". Даже отвечать им не буду. Осорбенно когда потратил дни копаясь в исходниках Spring. Прекрасно знаю как Spring работает, как использует пулы JDBC, накручивая вокруг них свой код. Тут то при работе с пулами jdbc коннектов напрямую возникают тонкие, сложно уловимые (на проме) проблемы. А когда вокруг еще код Spring - это вообще не реально разобраться в причинах.
Так что не надо советовать.
Мне все равно на чем писать. И на том и на сем много писал.
Да еще SpringBoot на нее сверху свое накладывает на чистый hibernate.
Я одном нагруженном (сейчас) модуле я поленился на голом SQL писать. Взял Hibernate (без Spring). А теперь и полностью переписывать как то не очень. Модуль отвественный и переделывать/перетестировать все что накопислось это и страшно и больно. Вопрос даже не во времени на переделку. Риски финансовые велики в случае сбоев/ошибок в ПО.
вот и приходится местами по мере нахождения узких высоконагруженных мест фактически на hibernate "sql" писать, что бы оптимизировать SQL запросы и транзакционность. Уж лучше бы сразу на голом SQL..
Фраза "это же удобно для прототипирования" - это дорога в ад. Когда неожиданно прототип превращается в высоконагруженный сервис. И жуешь потом этот кактус вечно.
Объективно оценить а сколько по факту движений за день. У меня есть такие знакомые. Со стороны видно. Они постоянно в движении (включая мелкие движения). Но сами этого не замечают. Для них это привычно.
Люди очень по разному себя видут если присмотреться (физическая активность).
Для обычного человека, даже если он в спортзал ходит, бегает и т.п., расход энергии в спорт зале мелочь по сравнению с расходом в просто в течении дня. А этот расход у всех очень разный.
А зря как то. При прочих равных, мышцы сами по себе в относительном покое (полный покой только у трупов) потребляют больше чем жир. Человеку с большей сухой мышечной массой (15% жира) требуется больше еды чем такому же по весу но, скажем типично офисному по сложению (25-30% жира).
Тренер в зале при весе 120кг (выглядит сухим и монстрообразным), и не прям так усилино напрягаясь по физическким нагрузкам, для того что бы просто поддерживать мышцы потребляет в 7000-8000 ккл в день. Причем все тщательно учитывает. Т.е. не с потолка цифры.
анаблики конечно жрет.. лично я не одобряю. но как пример того, сколько мышцы сами по себе требуют.
Тем кто использует Spring boot для нагруженных пром решений стоит несколько раз подумать "а стоит ли". И эта статья еще один намек на это.
Cлушаешь на HighLoad++ выступления "а что мы делали что бы Spring Boot приложения при старте не выжирали все ресурсы и как нам это не очень помогло" "не очень помогло" - это вывод не особо озвучен, но из результа в 10-15% после сложных приседаний это явно видно.
Отказался на проме от SpringBoot в принципе. Регулярно приходят из эксплуатации с вопросом "вот как бы при поднятии резервного сервера (сервисов на нем в количетве от 500 штук) сократить потребление ресурсов и уменьшить время старта". Если для приложений, где сам определил какая часть в какой последовательности стартует и что можно оптимизировать, как то можно что то сделать, то SpringBoot пока все не загрузит и не подготовит окружение для запуска прикладного кода - жрет ресурсы как свинья помои.
Кстати, здраствуйте ярые поклонники "не монолитов" где каждая мелкая хрень стартует отдельно в своем OS процессе.
Конечно писать на на SpringBoot проще. Как бы магия бинов и аннотаций (до тех пор, пока не слокнешься с нетривиальной проблемой/требованием от эксплуатации и не потратишь пару дней в копании исходников Spring) .
Но не принципиально сложнее, когда приходится руками организовывать все самому. Пусть даже в 2 раза больше времени потратитшь (в основном на продумываение архитектуры). Но за то потом не придется ночью вставать на инциденты с "не хватало памяти.. процессор 100% занят. Все зависло из за этого при старте"
Удобство программиста обратно пропорционально производительности и потреблению ресурсов сервиса. По моим наблюдениям.
Вводить руками 10000 вариантов пароля неудобно и долго.
И не нужно. После максимум 20 попыток (типично 5..10 по умолчаю вастройках) телефон заблокируется и примет только пароль блокировки. Если это Андройд. Про яблоки ничего не скажу. не интересовался и не сталкивался.
"Ученые покусали журналистов в голову". Особо умиляют примеры на arduino стиле кода. Люди открыли для себя, что оказывается, если работать напримую с железом, то можно сделать что то, что обычно либы запрещают/не дают сделать.
В ESP32 возможно, например, посылать Deauther Wifi пакеты физически. Но никто не называет "ESP32 - это инструмент для хакеров вредителей".
Если вам в обработке нужна каждая ms быстродействия - не используйте аннотации для таких вещей. А если в проде критично экономия ресурса для поднятия обработчиков - не используйте SpringBoot вообще.
А если все это не нужно, да.. конечно на SpringBoot писать удобнее. Но, как то ради интереса один сервис написал и на Spring и на просто java. Разница в объеме кода где то %30. На Spring лаконичнее и в целом читаемей. Разница в скорости старта от запуска (относительно дохлая виртуалка для тестов) 1.2 сек и 5 сек (Spring). Проверка прав доступа через аннотaции (Spring) vs фильтр (grizzly http) - разница в 3ms не в пользу аннотаций. Логирование вызова HTTP API через аннотацию сразу добавили 5ms на вызов. Разница между hibernate+Spring обертка и использованием голого jdbc - от 0 до 10ms (но все равно jdbc однозначно выигрывает).
Казалось бы мелочь. Но это не так для высоконагруженных систем. Кто то скажет, что на быстром серваке разница не ощутима. Может быть. Но не когда на проме под 500 сервисов поднимается. Особенно если на холодную.
И не слушал бы я на HighLoad выступление докладчика как они ускоряли запуск Spring приложений и какими методами. Не просто так проблему решали. А ресурсов сервера не хватало на старт. Мне показалось, что введение этих методов все одно на 100% проблему не решает но создает такой геморой эксплуатации, что это перекрывает "мне комфортно писать на Spring" разработчиков.
Предчувствую, что сейчас налетят и заклюют любители Spring :) Сразу скажу, мне на Spring комфортнее писать. Но не комфортно участвовать в ночных сборищах разборов инцидентов с нехваткой ресурсов и т.п. и решение проблем "а что делать" в ночное время или в стрессе "все пропало.. простой"
Если Вы считаете что пульс и давление явно коррелируются между собой - это Ваша личная проблема.
Если Вы считаете, что показаниям браслета по пульсу по сравнению с нагрудным кардиодатчиком во время тренировки можно доверять - это Ваша проблема.
Браслет сильно ошибается (занижает или завышает случайно) во время нагрузки (150 Вт в течении 30 минут) по сравнению с нагрудным и прямым подсчетом (банально по секундомеру).
А еще у вас проблема с общением. Снисходительный стиль Вашей заметки вызывает однозначную реакцию. И это точно ваша проблема.
Спорта! Профессионального. Т.е. когда у вас за тренировку более 10 км. А не 45 минут побултыхался в стиле "по собачьи".
Постоянны изгибания позвоночника и связанные с этим проблемы. Эпикондилит локтевого сустава. Повышенный износ сухожилий ротационной манжеты (особенно надосной) и пр.
Статья оставила неоднозначное впечатление. "+" за "топим за здоровый образ жизни" "-" уж очень рекламная (реклама T канала)
"Тренер" продающий программы - это ужас. Развод в чистом виде. Не ведитесь. Пофиг, что вы делает если нет цели стать "мистер олимпия", а просто есть желание "вспомнить что есть скелетная мускулатура". Если раньше не особо занимались, то отклик будет даже если просто "на гантелю посмотреть"
Просто заплатите тренеру в зале, что бы он поставил правильную технику что бы не убить суставы связки и сухожилия. Ну или online тренеру (по видео в режиме реального времени), как минимум.
Автор этого длинного и многословного текста похоже никогда не сталкивался с задачами переписывания действительно старого объемного ПО, на которое толком спецификаций нет и пр.
И не простого и понятного кусочка/модуля, а чего то более менее сложного и комплексного.
Я сталкивался.
Сводить все к синктаксису языков программирования и использования LLM вызывает у меня нервное хихикание. И явно отражает только теоретический "опыт" автора в этом вопросе.
В общем: "Что нам строит дом посторить: нарисуем - будем жить".
Когда 90% времени (в лучшем случае) тратишь не на само переписывание как таковое, с одного языка на другой, а на разборки "а зачем это и что это делает в конечном итоге". Не с точки зрения байтиков битиков, а высокоуровнево.
Даже, когда в целом понимаешь зачем и для чего, разбор занимает массу времени.
Особенно на "боковые" ветки логики, на которые в жизни внятных логов нет и никто не может сказать используется это и при каких условиях возникает.
Особенно весело, когда наступает фаза тестирования (нет ни тест кейзов ни общего знания как все целиком работает что бы их составить).
И когда переписанное ПО приносит неожиданные сюрпризы в "боковых" ветках логики (про которые никто не помнит и которые возникают неожиданно на бою).
А еще веселее, когда это ПО связано с финансами и любая ошибка в продакшн - это ооочень больно.
А "не протестированное ПО - это 100% не рабочее ПО". И даже прототестированное ПО - это на 50% рабочее ПО (с вероятностю 1/2. Либо встретишь в нем ошибку или не встретишь на этапе эксплуатации).
Кстати, это беда очень многих статей на хабре. Все сводится к кодированию. Я уже оочень давно занимаюсь разработкой ПО. Так вот кодирование - это совсем небольшая часть работы в разработке ПО.
И по большому счету пофиг на чем (язык, фреймворк). Основное - это понять что нужно (и понять/договорится что это именно то хочется получить).
Я вообще часто удивляюсь как люди друг друга еще понимают. У свой образ "реального мира в голове", а слова языка дают иллюзию, что этот образ "как бы один".
Признание облегчает совесть, но увеличивает срок.
Все что запомнил. Марина была небольшая. Посмотрел сейча по спутниковым снимкам. Не опознаю какая, но 100% не Алимос .
Я же писал, что ездил "баластом" и все организационные вещи не вникал. Как мне объяснили, яхта частная и сдавалась через агентсво (напрямую никто не сдает). Как ее нашли, через какое агенство - мне было тогда не интересно. Поездка вообще была бюджетной. Я очень удивился, что в сумме ночевка 3 суток в гостинице стоила почти как 7 дней моего вклада в аренду. Именно в аренду. Что там на топливо скидывались и на продукты на месте уже по факту.
Да. Такая яхта для прогулок. От острова к острову с ночевками либо в маринах либо разово в какой ни будь бухте.
Под прогулочной яхтой/катамароном я имел виду формат (в Тае) аренды на 10-15 чел в формате "от пляжа к пляжу вдоль берега". Чаще всего (в Тае) в ареду на неделю сдают с шкипетром, если в компании своего не будет. И в сумме, аренда на человека и еда - это приблизительно столько же, если то же время время на берегу (гостиницы 2* + поездки = 1000-1500$ в 2 недели у меня уходит в Тае). В сумме на яхте даже дешевле. Доп траты только на еду.
Мне такой отдых не зашел. Скучно. Компанию с дайверами под такой формат не нашел (может и нет таких арендных яхт с копрессором и местом под баллоны).
Так что, "прогулочный" не в смылсе длинны переходов, а в смысле "место переночевать, переместится на 20..50 км в строну и снова переночевать".
Яхты "для мыса горн" упомянул под впечатления ролика на ютюбе где показывалось путешествие как раз через мыс горн. Жуткие виды огромных волн, вахты с коротким сном в сырости и все это за нехилые деньги.
У нас разный опыт. Вы судите, исходя исключительно из своего опыта, и не допускате что существет что то другое типа бюджетной аренды мелкой (и довольно убитой жизнью) яхты на 3 каюты на 6-7 человек или катамарана в Тае для "пляжно/яхтного отдыха".
Я вообще не пытаюсь затрагивать в рассужения ту строну, которую не знаю. И говорил про свой личный (пусть и весьма ограниченный) опыт. И не более. Но все же личный опыт, а не со слов.
В марине, из которой в Афинах выходили, все яхты были до 30 футов. Почти все можно было взять в аренду на компании 6-7 человек. Все разномастные. Все частные.
Все это для аренды обычно под компании со своим шкипром любителем и такой же компании фанатиков яхт спорт. Полно тематических форумов на которых народ собирается и организовывает в складчину такие выезды погонять на регатах и пр. Попасть туда матросом - сложно. Баластом (пай в) - обычно без проблем. Но именно баластом :) Порулить и веревки подергать - очередь :)
По крайней мере было до 2022.
Вы говорите о другом классе аренды. Прогулочные катамараны.. красотки с бокалами шампанского на сандеке (утрирую). Как правило шкипер в комплекте, а иногда и команда минимальная в комплекте к аренде (не обязательно). Есть конечно и аренда больших яхт океанского класса (типа обойти мыс Горн). Но там запредельные цены и я с этим живьем не сталкивался.
Так что, если Вы с чем то не сталкивались, то не значит, что этого не существует.
В греции просто выдернуть граном из воды в марине в Афинах (опусить в воду, аренда стапеля и пр. не входит) это 200ойро.
Про Тунис ничего не знаю.
Довольно лукавые расчеты. А никто не задумывается откуда такие цены...
Попал как то яхту в качетве "баласта" (Греция). Остальной народ учился что бы получать международные корочки шкипера. А я так.. просто за компанию.
Вопросы к "преподавателю" "студентов" были как раз такого плана: "я же могу взять.. это же не дорого".
Он как раз и говорил в ответ: "купите. вложитесь.. поиграетесь пару отпусков, посчитаете сумму в год и будете продавать демпингуя - вот от этого такие цены".
Умалчивается, сколько стоит обслуживать (хотя бы просто выдернуть из воды краном).
Можно, конечно, просто купить, вложится в состояние "авось не утонет" и бросать в воде на год. Года на 2 хватит особено в южных морях. А потом на помойку. Все же это не автомобиль. А жить на яхте долго - это не для всех.
Все арендные яхты (ну в Греции точно) это чьи то. И сдают их в аренду, что бы по минимум отбить траты на содержание.
Конечно все это со слов шкипера, которого учил группу. Он не отговаривал. Просто объяснял расклады и подводные камни такого варианта как своя яхта.
Да. Слышал и такой вариант. Только на Axiom JDK особой разницы не заметно на тестах.
А еще можно вынести файлы *.class из jar архива. А еще можно *.class положить в FS созданный в RAM и.. иного еще я слышал путей (на коференциях и в кулуарах) как ускорить старт SpringBoot приложения.Включая даже такую экзотику, как собственный форк SpringBoot для того что бы делать "прогрев". (не помню что подразумевали авторы. давно было)
А можно просто не использовать SpringBoot для высоконагруженных сервисов Java которым требуется быстрый старт.
Есть опыт переписывания HTTP сервисов со Spring на "просто страрт из main http сервера с REST API+пул jdbc коннектов".
не так уж много дополнительно кода требуется, что бы явно указывать зависмости, пользоваться @Ingect "из коробки" и самому обрабатывать анотации там где это нужно, а не по всем классам прикладного кода. Ничего сложного в этом нет.
после такой переделки, ресурсы, потребляемые сервисом для старта сокращаются кардинально.
Есть с чем сравнивать. И это важно для прома, когда из железа нужно выжать максимум.
Почему то все просто помешались на этом SpringBoot. Как будто ничего другого нет.
SpringBoot, в сущьности, довольно простой, если брать основу (автоматические связи между компонентами прикладного кода). А все остальное в нем, это зачастую кривонаписанные обертки поверх других продуктов/либ (Hibernate, Http сервера, kafka и пр.).
А насчет Jooq... Когда тратишь кучу времни, что бы найти как добавить в SQL, который порождает Hibernate, специфичный вариант синтаксиса (а hibernate типа как бы "сам лучше знает чем я"), то собрать грабли на другой дорожке уже не хочется.
Spring обертывет своим кодом и kafka и Tomcat под свои особенности.
Но вообще никто не мешает использовать kafka даже внутри Springboot напрямую.
Особенно, когда хочется использовать какую ни будь фичу либы клиента kafka, а разработчики SpringBoot не захотели (посчитали не нужным) вынести ее в API Spring.
..
final KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
..
while (!Thread.interrupted()) {
..
ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(dt));
То же самое и с реализацией API web, которая есть у всех Http серверов (tomcat, grizzly, jetty,..)
Дело вкуса, но стандарт анотаций javax.ws.rs.* @POSTT, @Path, @Consumes,..) мне больше нравится чем "стандарт" анотаций Spring @RequestMappingg). Хотя это субъективно и не имеет никакого принципиального значения.
Кстати, во всех Http серверах "из коробки" есть поддержка @Inject в реализации классов API. Конечно, не автоматом сборка бинов, а нужно руками при старте сервера указать какие классы хочешт инжекнуть и как.
В общем, список того что мне не нравится в SpringBoot (в порядке приоритета)
Автоматический сбор зависимостей это удобство для программиста, но большая нагрузка и ресурсы сервера на старте программы.
Оболочки Spring вокруг стандартных либ подходят для 99% задач, но когда возникает что то не стандартное, то либо нужно пробиваться к нужным вызовам через рефлексию, по пути долго матерясь и копаясь в исходниках Spring или использовать вызовы либ напрямую. В общем, шаг в строну - уже проблема.
Красота и удобство кода не = производительности. Местами приходилось красивый "функциональный" вызов stream заменять на не красиывый for ради экономии долей ms.
Да. Сейчас набежит куча советчиков типа "советую посмотреть в сторону Spring Data Jdbc". Даже отвечать им не буду. Осорбенно когда потратил дни копаясь в исходниках Spring.
Прекрасно знаю как Spring работает, как использует пулы JDBC, накручивая вокруг них свой код.
Тут то при работе с пулами jdbc коннектов напрямую возникают тонкие, сложно уловимые (на проме) проблемы. А когда вокруг еще код Spring - это вообще не реально разобраться в причинах.
Так что не надо советовать.
Мне все равно на чем писать. И на том и на сем много писал.
Да еще SpringBoot на нее сверху свое накладывает на чистый hibernate.
Я одном нагруженном (сейчас) модуле я поленился на голом SQL писать. Взял Hibernate (без Spring).
А теперь и полностью переписывать как то не очень. Модуль отвественный и переделывать/перетестировать все что накопислось это и страшно и больно.
Вопрос даже не во времени на переделку. Риски финансовые велики в случае сбоев/ошибок в ПО.
вот и приходится местами по мере нахождения узких высоконагруженных мест фактически на hibernate "sql" писать, что бы оптимизировать SQL запросы и транзакционность.
Уж лучше бы сразу на голом SQL..
Фраза "это же удобно для прототипирования" - это дорога в ад. Когда неожиданно прототип превращается в высоконагруженный сервис. И жуешь потом этот кактус вечно.
Объективно оценить а сколько по факту движений за день.
У меня есть такие знакомые. Со стороны видно. Они постоянно в движении (включая мелкие движения). Но сами этого не замечают. Для них это привычно.
Люди очень по разному себя видут если присмотреться (физическая активность).
Для обычного человека, даже если он в спортзал ходит, бегает и т.п., расход энергии в спорт зале мелочь по сравнению с расходом в просто в течении дня. А этот расход у всех очень разный.
А зря как то. При прочих равных, мышцы сами по себе в относительном покое (полный покой только у трупов) потребляют больше чем жир. Человеку с большей сухой мышечной массой (15% жира) требуется больше еды чем такому же по весу но, скажем типично офисному по сложению (25-30% жира).
Тренер в зале при весе 120кг (выглядит сухим и монстрообразным), и не прям так усилино напрягаясь по физическким нагрузкам, для того что бы просто поддерживать мышцы потребляет в 7000-8000 ккл в день. Причем все тщательно учитывает. Т.е. не с потолка цифры.
анаблики конечно жрет..
лично я не одобряю. но как пример того, сколько мышцы сами по себе требуют.
Тем кто использует Spring boot для нагруженных пром решений стоит несколько раз подумать "а стоит ли".
И эта статья еще один намек на это.
Cлушаешь на HighLoad++ выступления "а что мы делали что бы Spring Boot приложения при старте не выжирали все ресурсы и как нам это не очень помогло"
"не очень помогло" - это вывод не особо озвучен, но из результа в 10-15% после сложных приседаний это явно видно.
Отказался на проме от SpringBoot в принципе. Регулярно приходят из эксплуатации с вопросом "вот как бы при поднятии резервного сервера (сервисов на нем в количетве от 500 штук) сократить потребление ресурсов и уменьшить время старта". Если для приложений, где сам определил какая часть в какой последовательности стартует и что можно оптимизировать, как то можно что то сделать, то SpringBoot пока все не загрузит и не подготовит окружение для запуска прикладного кода - жрет ресурсы как свинья помои.
Кстати, здраствуйте ярые поклонники "не монолитов" где каждая мелкая хрень стартует отдельно в своем OS процессе.
Конечно писать на на SpringBoot проще. Как бы магия бинов и аннотаций (до тех пор, пока не слокнешься с нетривиальной проблемой/требованием от эксплуатации и не потратишь пару дней в копании исходников Spring) .
Но не принципиально сложнее, когда приходится руками организовывать все самому. Пусть даже в 2 раза больше времени потратитшь (в основном на продумываение архитектуры). Но за то потом не придется ночью вставать на инциденты с "не хватало памяти.. процессор 100% занят. Все зависло из за этого при старте"
Удобство программиста обратно пропорционально производительности и потреблению ресурсов сервиса. По моим наблюдениям.
И не нужно. После максимум 20 попыток (типично 5..10 по умолчаю вастройках) телефон заблокируется и примет только пароль блокировки. Если это Андройд. Про яблоки ничего не скажу. не интересовался и не сталкивался.
В чем смысл тогда?
"Ученые покусали журналистов в голову". Особо умиляют примеры на arduino стиле кода.
Люди открыли для себя, что оказывается, если работать напримую с железом, то можно сделать что то, что обычно либы запрещают/не дают сделать.
В ESP32 возможно, например, посылать Deauther Wifi пакеты физически. Но никто не называет "ESP32 - это инструмент для хакеров вредителей".
Если вам в обработке нужна каждая ms быстродействия - не используйте аннотации для таких вещей.
А если в проде критично экономия ресурса для поднятия обработчиков - не используйте SpringBoot вообще.
А если все это не нужно, да.. конечно на SpringBoot писать удобнее.
Но, как то ради интереса один сервис написал и на Spring и на просто java.
Разница в объеме кода где то %30. На Spring лаконичнее и в целом читаемей.
Разница в скорости старта от запуска (относительно дохлая виртуалка для тестов) 1.2 сек и 5 сек (Spring). Проверка прав доступа через аннотaции (Spring) vs фильтр (grizzly http) - разница в 3ms не в пользу аннотаций. Логирование вызова HTTP API через аннотацию сразу добавили 5ms на вызов.
Разница между hibernate+Spring обертка и использованием голого jdbc - от 0 до 10ms (но все равно jdbc однозначно выигрывает).
Казалось бы мелочь. Но это не так для высоконагруженных систем.
Кто то скажет, что на быстром серваке разница не ощутима. Может быть. Но не когда на проме под 500 сервисов поднимается. Особенно если на холодную.
И не слушал бы я на HighLoad выступление докладчика как они ускоряли запуск Spring приложений и какими методами. Не просто так проблему решали. А ресурсов сервера не хватало на старт.
Мне показалось, что введение этих методов все одно на 100% проблему не решает но создает такой геморой эксплуатации, что это перекрывает "мне комфортно писать на Spring" разработчиков.
Предчувствую, что сейчас налетят и заклюют любители Spring :)
Сразу скажу, мне на Spring комфортнее писать. Но не комфортно участвовать в ночных сборищах разборов инцидентов с нехваткой ресурсов и т.п. и решение проблем "а что делать" в ночное время или в стрессе "все пропало.. простой"
Если Вы считаете что пульс и давление явно коррелируются между собой - это Ваша личная проблема.
Если Вы считаете, что показаниям браслета по пульсу по сравнению с нагрудным кардиодатчиком во время тренировки можно доверять - это Ваша проблема.
Браслет сильно ошибается (занижает или завышает случайно) во время нагрузки (150 Вт в течении 30 минут) по сравнению с нагрудным и прямым подсчетом (банально по секундомеру).
А еще у вас проблема с общением. Снисходительный стиль Вашей заметки вызывает однозначную реакцию. И это точно ваша проблема.
Мезркий банк. Спамерам из этого банка отдельное место и котел в аду.
Всех своих знакомых оповещу, что бы не пользовались услугами этого банка.
Я персонально Вам что то сделал?. Вы меня лично знаете? Нет. Или Вы по жизни рады ярлыки вешать на людей которых не знает в принципе.
Если это это просто Ваш стиль общения, то зачем с Вами общаться вообще.
Плавание очень травматичный вид спорта.
Спорта! Профессионального. Т.е. когда у вас за тренировку более 10 км.
А не 45 минут побултыхался в стиле "по собачьи".
Постоянны изгибания позвоночника и связанные с этим проблемы. Эпикондилит локтевого сустава. Повышенный износ сухожилий ротационной манжеты (особенно надосной) и пр.
Впрочем, любой проф.спорт - это не про здоровье.
Статья оставила неоднозначное впечатление.
"+" за "топим за здоровый образ жизни"
"-" уж очень рекламная (реклама T канала)
"Тренер" продающий программы - это ужас. Развод в чистом виде.
Не ведитесь. Пофиг, что вы делает если нет цели стать "мистер олимпия", а просто есть желание "вспомнить что есть скелетная мускулатура". Если раньше не особо занимались, то отклик будет даже если просто "на гантелю посмотреть"
Просто заплатите тренеру в зале, что бы он поставил правильную технику что бы не убить суставы связки и сухожилия. Ну или online тренеру (по видео в режиме реального времени), как минимум.