Сначала вы распинаетесь о том, как важно все логировать и ничего не терять, а затем используете аспекты спринга, которые работают только при вызове метода из другого класса. Ну то есть вы дернете метод с такой аннотацией изнутри класса или повесите ее на приватный метод - и все эти вызовы останутся без логирования вообще.
Действительно, "простой и очевидный" способ, прям то, что нужно для "профилактики"
По сути, вся статья о том, что берем готовый образ докера и шлем ему запросы. Ни подробностей, ни нюансов, даже стриминг не настроен. Как-то бесполезно, уж извините
С одной стороны не особо нужен, а с другой, он использует те же аннотации, что и контроллер. Это позволяет выделить контракт взаимодействия в интерфейс, а потом имплементировать его как в контроллере, так и в клиенте (просто наследуемся от интерфейса еще одним, который помечен аннотацией @FeignClient)
А смысл кликать по рекламе и размывать свои предпочтения? По итогу, на каждом таком клике получит деньги тот же Яндекс, а компании, которые купили рекламу, просто сольют свои деньги вникуда.
Ох уж эти наполеоновские планы. Жаль только, что все кончится на этапе проверки наличия признаков генерации текста при получении компанией сопроводительного письма.
Но я всё же надеюсь, что у вас что-то да получится, и вы окончательно доломаете найм. Возможно, хотя бы тогда что-то изменится в лучшую сторону.
С появлением виртуальных потоков я бы добавил, что для IO-bound задач в принципе больше нет необходимости в пуле потоков, будет достаточно Executors.newVitrualThreadPerTaskExecutor()
Спасибо за статью. Про паттерны здорово, но вот примеры кода... Не помешало бы сделать оговорку о том, как реализуется кеш силами Spring в реальном приложении (явно же не так)
Удаление старых записей стоит еще и по статусу проверять, а то мало ли что.
А как же Хабр? Могли бы и его в белый список добавить
Ну то есть кривой код пишете вы, а проблема - во мне. Очень логично.
Спасибо, посмеялся от души...
Сначала вы распинаетесь о том, как важно все логировать и ничего не терять, а затем используете аспекты спринга, которые работают только при вызове метода из другого класса. Ну то есть вы дернете метод с такой аннотацией изнутри класса или повесите ее на приватный метод - и все эти вызовы останутся без логирования вообще.
Действительно, "простой и очевидный" способ, прям то, что нужно для "профилактики"
спасибо за перевод!
очень важное замечание, пожалуй, важнее самой статьи)
По сути, вся статья о том, что берем готовый образ докера и шлем ему запросы. Ни подробностей, ни нюансов, даже стриминг не настроен. Как-то бесполезно, уж извините
С одной стороны не особо нужен, а с другой, он использует те же аннотации, что и контроллер. Это позволяет выделить контракт взаимодействия в интерфейс, а потом имплементировать его как в контроллере, так и в клиенте (просто наследуемся от интерфейса еще одним, который помечен аннотацией @FeignClient)
Я бы может и согласился на гибрид, будь офис в 10 минутах пешком.
Тратить на дорогу деньги и несколько часов времени - а ради чего? Чтобы отвлекаться не на телефон, а на общение с коллегами? Ну-ну... Плавали, знаем.
Ну хорошо, как вы предлагаете выводить на рынок новый продукт, если вы против рекламы? Даже интересно.
Вот примерно из-за такого отношения к окружающим наш мир идеальным и не станет
В идеальном мире, возможно, так бы и произошло. А в нашем просто сделают крайним таргетолога.
А смысл кликать по рекламе и размывать свои предпочтения? По итогу, на каждом таком клике получит деньги тот же Яндекс, а компании, которые купили рекламу, просто сольют свои деньги вникуда.
Только хуже станет, получается.
Можно попробовать использовать InheritableThreadLocal
Ох уж эти наполеоновские планы. Жаль только, что все кончится на этапе проверки наличия признаков генерации текста при получении компанией сопроводительного письма.
Но я всё же надеюсь, что у вас что-то да получится, и вы окончательно доломаете найм. Возможно, хотя бы тогда что-то изменится в лучшую сторону.
С появлением виртуальных потоков я бы добавил, что для IO-bound задач в принципе больше нет необходимости в пуле потоков, будет достаточно Executors.newVitrualThreadPerTaskExecutor()
Что-то я не понял, как "одиночный кодер" вяжется с вашим выводом
А как бы вы перевели? Искренне интересно.
Спасибо за статью. Про паттерны здорово, но вот примеры кода... Не помешало бы сделать оговорку о том, как реализуется кеш силами Spring в реальном приложении (явно же не так)
Впечатляет. Бывают же люди...