Хвала святым сусликам, да. :) Меня это дело задело, можно сказать, по касательной.
Но это не меняет того, что экосистема spring-а - монстр, пусть маленький, но всё же. Как IoC к нему претензий у меня почти нет. Да и те, что имеются, - можно сказать, вкусовщина.
А вот ко всему остальному - полно. Стоит только чуть-чуть попытаться отойти от предполагаемого авторами шаблона использования, тут же начинается борьба с фреймворком. Многие вещи переусложнены. И зачастую выходит так, что вместо использования готовых решений, которые вроде как предоставляются, проще написать своё, компактное и без лишней шелухи.
А ещё есть SpringBoot - любитель понапихать в контекст того, чего не просили, и выжрать выделенную память никому ненужными бинами, которые создаются и никогда не используются.
Рекомендую, если ещё не смотрели, рекламируемую кору я, конечно же, не пробовал, но вот всё, что сказано про spring, я люто-бешено плюсую.
18 год, в это время переводы по номеру телефона в Сбере уже во всю гонялись. Причём даже без всяких приложений, просто СМС с суммой и номером адресата.
TL/DR Сия вундервафля помогает решать проблемы, которых у вас не было бы, если бы вы не использовали инструмент, который не знаете и не умеете применять.
А вообще, конечно, спринг, появившийся, чтобы убить дракона (EJB), сам стал им давным давно.
TL/DR final-метод, который сразу же бросается в глаза, т.к. подобные методы пишутся чуть реже, чем никогда, - причина "расследования".
Long story short: я сделяль.
Как по мне - нет. Во-первых, начал с фокусника, потом перешёл к играющему мальчику. Переключения контекста всегда надо стараться избегать. Во-вторых, разобрано то, что по 100500 раз уже было описано по аналогичной тематике. В том числе и в документации спринга. Но кому она нужна, да?
Зависимость "на себя" это тоже костыли, которых лучше избегать. Но как quickfix, с последующим рефакторином, конечно, можно и использовать. Главное, чтобы это не вылилось в постоянный шаблон использования.
При чём тут есть морда или нет? Любые приходящие из вне данные априори невалидны, пока не доказано обратное. И не важно насколько ты контролируешь источник этих данных, хоть на все 146%, всё равно валидация на входе обязана присутствовать.
Когда-то давно @Skipy написал о кодировках гораздо более содержательную и полезную статью.
А это неважно. :)
А ещё многие компании путают микросервисы с распределённым монолитом.
То, о чём рассказывается на публичных меропиятиях, хорошо, если на процентов 50-60 соответствует действительности.
А так-то оно конечно... Ютуб, Твиттер, например, у того же Алекса Сюя в книжке разобраны.
Я б посмотрел, но кто ж мне даст?
Хвала святым сусликам, да. :) Меня это дело задело, можно сказать, по касательной.
Но это не меняет того, что экосистема spring-а - монстр, пусть маленький, но всё же. Как IoC к нему претензий у меня почти нет. Да и те, что имеются, - можно сказать, вкусовщина.
А вот ко всему остальному - полно. Стоит только чуть-чуть попытаться отойти от предполагаемого авторами шаблона использования, тут же начинается борьба с фреймворком. Многие вещи переусложнены. И зачастую выходит так, что вместо использования готовых решений, которые вроде как предоставляются, проще написать своё, компактное и без лишней шелухи.
А ещё есть SpringBoot - любитель понапихать в контекст того, чего не просили, и выжрать выделенную память никому ненужными бинами, которые создаются и никогда не используются.
Рекомендую, если ещё не смотрели, рекламируемую кору я, конечно же, не пробовал, но вот всё, что сказано про spring, я люто-бешено плюсую.
18 год, в это время переводы по номеру телефона в Сбере уже во всю гонялись. Причём даже без всяких приложений, просто СМС с суммой и номером адресата.
TL/DR Сия вундервафля помогает решать проблемы, которых у вас не было бы, если бы вы не использовали инструмент, который не знаете и не умеете применять.
А вообще, конечно, спринг, появившийся, чтобы убить дракона (EJB), сам стал им давным давно.
Не взлетит.
Прошу прощения за грубость, но, как мне видится, варианта, когда вся эта порнография будет работать только 2:
Жёны и сын такие же поехавшие на календарях и планировании как и автор.
Автору абсолютно насрать на мнение остальных, и всё взаимодействие с собой он строит через календарь. Нет в календаре - автор ничего не делает.
TL/DR
final-метод, который сразу же бросается в глаза, т.к. подобные методы пишутся чуть реже, чем никогда, - причина "расследования".Как по мне - нет. Во-первых, начал с фокусника, потом перешёл к играющему мальчику. Переключения контекста всегда надо стараться избегать. Во-вторых, разобрано то, что по 100500 раз уже было описано по аналогичной тематике. В том числе и в документации спринга. Но кому она нужна, да?
И жди иски от JetBrains.
Зачем же тогда цензурить? Всё же подожду, что по этому поводу скажет товарищ @avegad.
На чём? На своих галлюцинациях?
А что скрывается за "...ить"? С остальными, вроде, проблем в дешифровке не возникло. Но это "...ить", да ещё и в сочетании с последующим "...ать".
Зависимость "на себя" это тоже костыли, которых лучше избегать. Но как quickfix, с последующим рефакторином, конечно, можно и использовать. Главное, чтобы это не вылилось в постоянный шаблон использования.
Если бин является зависимостью ТОЛЬКО для опционального бина, то он тоже должен быть опциональным. И не надо никаких ленивостей.
Я на 146% уверен, что всё можно ещё ускорить, только обуздав свой стримоз.
Двойной проход на ровном месте, нахера и, главное, зачем? Можно же просто
stream.forEach(result::add)Если два бина зависят друг от друга - это циклическая зависимость.
Болван.
@Lazy- это подорожник на открытый перелом. Циклическую зависимость надо разрывать, а не вставлять костыли.При чём тут есть морда или нет? Любые приходящие из вне данные априори невалидны, пока не доказано обратное. И не важно насколько ты контролируешь источник этих данных, хоть на все 146%, всё равно валидация на входе обязана присутствовать.
Тоже вопрос без правильного ответа.