Ограничения касаются, по сути, только вывода денег с кошелька на карту. Все остальные функции продолжают работать. Можно как и раньше оплатить стим, оплатить что-либо в интернете, оплатить ЖКУ
Киви также написало каким образом можно сейчас вывести деньги - оплатить мобильную связь, вывести на другой кошелек по типу ЮМани
А вообще странная фигня, зачем ЦБ наложил ограничения для клиентов - по сути сделав плохо именно клиентам, если нарушения у киви были в отчетности. Могли бы не говнять обычным людям и наложить, например, на компанию штраф
В спринге, как мы знаем, существует контекст - место, где лежат уже созданные и настроенные бины. Бины - по сути это те же объекты классов (или объекты прокси классов). Магия спринга заключается в том, что он за нас создает и собирает бины, а затем кладет их в контекст В спринге существует 4 способа объявить бин: - XML конфигурация - самый первый способ, который появился в спринге. - Конфигурация с помощью аннотаций - когда мы ставим над нашим компонентом @Component, @Service, @Repository и так далее - Java конфигурация - когда прописываем в java файле бины - Groovy аннотация - задаем бин в файле груви
Для обычных пользователей после объявления бина одним из 4 способов какая-либо работа заканчивается, так как далее за нас все делает спринг
В спринге же начинается процесс настройки контекста. Первый этап - считать информацию из конфигурационных файлов и на ее основе создать для каждого бина BeanDefinition, на основе которых дальнейшие процессы уже создадут сами бины
Хорошая статья про конфигурации бинов Хорошая статья про этапы инициализации контекста
Спасибо за ваш комментарий! Согласен, что универсальность теряется из-за невозможности использования различных реализаций для различных классов-оберток. Добавил комментарий про этот момент в статью
Данную негибкость возможно решить, например, при помощи инжекта мапы с сервисами. Однако, при реализации оказалось, что изменения довольно сильно усложняют проект в рамках целей статьи. Поэтому я не стал включать изменения в статью и проект
Пожалуй, хочется резюмировать все выше сказанное и, быть может, добавить что-то от себя. А как итог ответить автору почему же его статью так сильно заминусовали (хотя вообще странно как модераторы ее пропустили)
Если коротко, Янгалин Герман, хабр - это скорее про технические статьи, а не про ублажение своего эго. На хабр идут не для того, чтобы узнать автобиографию малоизвестного человека
А теперь немного подробностей: По целям статьи: Хабр ждет статьи о том, как можно сделать ту или иную штуку, как работает то или иное, как добиться успеха на хакатоне, в конце концов. Статья про самопиар явно будет восприниматься в штыки. Прежде чем публиковаться на данном ресурсе - ознакомься хотя бы с ним. Что тут публикуют, за что плюсы ставят. Из статьи явно надо убрать личные фото и бесчисленное фото наград, на которые большинству будет пофиг. По оформлению статьи: Зачем вообще писать 2 огромных блока в начале и в конце с благодарностями и типо полезными ссылками (даже если статья кому-то покажется полезной - он сам сможет загуглить конкретную секцию).
И самое главное запомните: «Трудные времена создают сильных людей. Сильные люди создают хорошие времена. Хорошие времена создают слабых людей. А слабые людей создают тяжелые времена».
Подумайте к чему я это сказал)
Вообще, если уж на то пошло, это сказал не ты, а Майкл Хопф
По содержанию статьи: Ты пишешь, что тебе в какой-то момент жизни уже удалось самореализоваться. Залезаем в гугл и вытаскиваем определение
Самореализация - осуществление своего человеческого назначения, призвания
Кажется, для самореализации нужно стать полезным обществу. Попробуй найти работу и тогда, если через хотя бы год работы ты все еще будешь чувствовать, что тебе нравится твоя стезя - можно будет сказать, что ты самореализовался
Как исправить статью, чтобы она начала приносить пользу (субъективное мнение): Попробуй сузить круг рассказа - расскажи, например, о том, каким способом ты реализовывал задачу на нти. Быть может это окажется хороший вариант (в противном случае тебе об этом подскажут в комментах, такое уж Российской комьюнити) и ты сможешь кому-то принести пользы. Либо же можешь написать, например, о своем опыте организации хакатона, рассказав о каких-то неочевидных моментах. Старайся писать меньше позерства, так как людям обычно это не нравится (хотя, думаю, ты это уже заметил).
По поводу решения сложным способом не самой сложной задачи - тут двоякий момент, так как по итогу мы имеем просто стартер. А, как говориться, мой стартер всегда со мной. Если проблема в одном месте - данный подход, скорее всего, не имеет смысла использовать. Однако применению такого подхода можно найти множества - различные дополнительные обработки ответов точек входа - это не обязательно обертка ответов. Данный подход скорее ближе к AOP для узкого места применения - и наследует от этого подхода как положительные стороны, так и отрицательные
По поводу реализации интерфейса двумя классами - да, вы совершенно правы, в данном случае проект не запустится с ошибкой спринга о том, что 2 класса претендуют на место 1 бина. Так как это pet проект, то я намеренно не стал обрабатывать данный exception (хотя мне кажется, нет большой необходимости это делать в стартере) и оставил ответственность на человека, использующего стартер. Проблему можно довольно просто решить с помощью использования @Primary . Так же возможным решением будет использование @Qualifier на стороне стартера
Что, если нам мало в сервисе только объекта для получения дополнительной информации, а нужен например еще параметр из request или еще откуда-то?
Вы в праве доработать стартер до того, что необходимо вам в вашей задачи. К тому же, метод beforeBodyWrite дает большие возможности в функциональном его использовании. Среди параметров есть и ServerHttpRequest request, ServerHttpResponse response
Ограничения касаются, по сути, только вывода денег с кошелька на карту. Все остальные функции продолжают работать. Можно как и раньше оплатить стим, оплатить что-либо в интернете, оплатить ЖКУ
Киви также написало каким образом можно сейчас вывести деньги - оплатить мобильную связь, вывести на другой кошелек по типу ЮМани
А вообще странная фигня, зачем ЦБ наложил ограничения для клиентов - по сути сделав плохо именно клиентам, если нарушения у киви были в отчетности. Могли бы не говнять обычным людям и наложить, например, на компанию штраф
Все с офф сайта https://promo.qiwi.com/qiwitoday/
Словом парсирование я обозначил именно этот процесс.
Определение из гугла:
В спринге, как мы знаем, существует контекст - место, где лежат уже созданные и настроенные бины. Бины - по сути это те же объекты классов (или объекты прокси классов). Магия спринга заключается в том, что он за нас создает и собирает бины, а затем кладет их в контекст
В спринге существует 4 способа объявить бин:
- XML конфигурация - самый первый способ, который появился в спринге.
- Конфигурация с помощью аннотаций - когда мы ставим над нашим компонентом @Component, @Service, @Repository и так далее
- Java конфигурация - когда прописываем в java файле бины
- Groovy аннотация - задаем бин в файле груви
Для обычных пользователей после объявления бина одним из 4 способов какая-либо работа заканчивается, так как далее за нас все делает спринг
В спринге же начинается процесс настройки контекста. Первый этап - считать информацию из конфигурационных файлов и на ее основе создать для каждого бина BeanDefinition, на основе которых дальнейшие процессы уже создадут сами бины
Хорошая статья про конфигурации бинов
Хорошая статья про этапы инициализации контекста
Спасибо за ваш комментарий! Согласен, что универсальность теряется из-за невозможности использования различных реализаций для различных классов-оберток. Добавил комментарий про этот момент в статью
Данную негибкость возможно решить, например, при помощи инжекта мапы с сервисами. Однако, при реализации оказалось, что изменения довольно сильно усложняют проект в рамках целей статьи. Поэтому я не стал включать изменения в статью и проект
Дааа, было много комментариев про статью.
Пожалуй, хочется резюмировать все выше сказанное и, быть может, добавить что-то от себя. А как итог ответить автору почему же его статью так сильно заминусовали (хотя вообще странно как модераторы ее пропустили)
Если коротко, Янгалин Герман, хабр - это скорее про технические статьи, а не про ублажение своего эго. На хабр идут не для того, чтобы узнать автобиографию малоизвестного человека
А теперь немного подробностей:
По целям статьи:
Хабр ждет статьи о том, как можно сделать ту или иную штуку, как работает то или иное, как добиться успеха на хакатоне, в конце концов. Статья про самопиар явно будет восприниматься в штыки. Прежде чем публиковаться на данном ресурсе - ознакомься хотя бы с ним. Что тут публикуют, за что плюсы ставят. Из статьи явно надо убрать личные фото и бесчисленное фото наград, на которые большинству будет пофиг.
По оформлению статьи:
Зачем вообще писать 2 огромных блока в начале и в конце с благодарностями и типо полезными ссылками (даже если статья кому-то покажется полезной - он сам сможет загуглить конкретную секцию).
Вообще, если уж на то пошло, это сказал не ты, а Майкл Хопф
По содержанию статьи:
Ты пишешь, что тебе в какой-то момент жизни уже удалось самореализоваться. Залезаем в гугл и вытаскиваем определение
Кажется, для самореализации нужно стать полезным обществу. Попробуй найти работу и тогда, если через хотя бы год работы ты все еще будешь чувствовать, что тебе нравится твоя стезя - можно будет сказать, что ты самореализовался
Как исправить статью, чтобы она начала приносить пользу (субъективное мнение):
Попробуй сузить круг рассказа - расскажи, например, о том, каким способом ты реализовывал задачу на нти. Быть может это окажется хороший вариант (в противном случае тебе об этом подскажут в комментах, такое уж Российской комьюнити) и ты сможешь кому-то принести пользы. Либо же можешь написать, например, о своем опыте организации хакатона, рассказав о каких-то неочевидных моментах. Старайся писать меньше позерства, так как людям обычно это не нравится (хотя, думаю, ты это уже заметил).
По поводу решения сложным способом не самой сложной задачи - тут двоякий момент, так как по итогу мы имеем просто стартер. А, как говориться, мой стартер всегда со мной. Если проблема в одном месте - данный подход, скорее всего, не имеет смысла использовать. Однако применению такого подхода можно найти множества - различные дополнительные обработки ответов точек входа - это не обязательно обертка ответов. Данный подход скорее ближе к AOP для узкого места применения - и наследует от этого подхода как положительные стороны, так и отрицательные
По поводу реализации интерфейса двумя классами - да, вы совершенно правы, в данном случае проект не запустится с ошибкой спринга о том, что 2 класса претендуют на место 1 бина. Так как это pet проект, то я намеренно не стал обрабатывать данный exception (хотя мне кажется, нет большой необходимости это делать в стартере) и оставил ответственность на человека, использующего стартер. Проблему можно довольно просто решить с помощью использования @Primary . Так же возможным решением будет использование @Qualifier на стороне стартера
Вы в праве доработать стартер до того, что необходимо вам в вашей задачи. К тому же, метод beforeBodyWrite дает большие возможности в функциональном его использовании. Среди параметров есть и ServerHttpRequest request, ServerHttpResponse response